This chapter addresses size estimat

This chapter addresses size estimating. It starts with a brief description of conceptual design and then covers proxy-based estimating. Chapter 6 describes the
PROBE method for using proxies to make size and time estimates. As shown in
Figure 4.1 in Chapter 4 (see p. 63), the PSP planning process starts with the conceptual design. This provides the basis for the size and resource estimates. At the
outset, you will know relatively little about the planned product, so your estimates
will be least accurate. Because you must presumably commit to a delivery date,
however, you must make the best estimate that you can. This chapter describes
how to identify the parts of a planned product and estimate their sizes.
5.1 Size Estimating Principles
In principle, estimates are made by comparing the planned job with previous jobs.
By breaking planned products into multiple smaller parts and comparing each part
with data on similar parts of prior products, you can judge the size of the new
product. This strategy works well for estimating almost any kind of development
work. However, it requires data on the products you have developed and the work
required to develop them. You also need a method for using historical data to make
the estimates.
This divide-and-conquer estimating strategy has the advantage of scaling up.
That is, once you have learned to make accurate estimates for the PSP exercises,
you can use the identical methods to estimate larger jobs. The only difference is
that you will have to divide bigger jobs into more parts or get data on larger parts.
In planning a PSP project, I use the term product to refer to the end item produced by the project and I use the term parts to refer to the elements of a product,
whatever you plan to call them. Depending on the type of development, the parts
could be systems, subsystems, components, classes, procedures, databases, or
whatever term best applies to that particular product. For example, when I estimate a C++ program, the parts are classes. With Object Pascal, they would be objects, and with database work, they would be fields, tables, or queries. If the
product’s parts have even smaller elements, such as methods, functions, or procedures, I call them items.
5.2 The Conceptual Design
When first making a plan to develop a product, you may generally understand the
requirements but little else. The estimating challenge is then to predict the size of
this vaguely defined product and the time required to develop it. Because no one
can know in advance how big a planned product will be or how long it will take to
develop, estimating will always be an uncertain process. Therefore, you need to
use the best product requirements and historical data you can get.
With the PSP, you make a size estimate first and then make the development
time estimate. For the size estimate to be reasonably accurate, it must be based on
an initial design concept, and that conceptual design must reflect the way you plan
to build the product. As noted in Chapter 4 (see p. 63), the conceptual design defines a preliminary design approach and names the expected product parts and
their functions. Do not produce the complete design during planning; just postulate the parts you will need and the functions they will perform.
For an accurate estimate, you must refine the conceptual design to the level
of the parts you know how to build. Next, check for historical data on similar parts.
If a part does not resemble anything in your historical records, see if you have refined the conceptual design to the proper level. Assuming you have a reasonably
complete and well-structured parts database, you will likely find that the part is a
composite of several more basic parts. If so, refine it into those more basic parts.
If a conceptual part is at the right level and still does not look like any of your existing part data, estimate it as the first of a new kind of part. In doing so, compare
this part to other product parts in the database to get a feel for their relationships
70 Chapter 5 Software Estimating
and then make your best intuitive estimate of its size. Then, after you have completed the development work, measure the size of the new parts and enter these
data into your database for use in estimating future work.
5.3 Proxy-Based Estimating
Consider the example of construction. In home building, the number of square feet
of living space provides a basis for estimating construction costs. Few people,
however, can visualize the house they want in terms of square feet. They think of
number of bedrooms and bathrooms. Software estimating has similar problems. If
we could judge the number of database relations or LOC for a product requirement, we could probably make a pretty good estimate of that product’s size. Unfortunately, few people can directly judge how many LOC or database elements it
would take to meet a product requirement.
What is needed is some proxy that relates product size to the functions we
can visualize. A proxy is a substitute or a stand-in. Assuming it is easier to visualize the proxy than the size measure, the proxy can help you to judge a product’s
likely size. Examples of proxies are classes, tables, fields, or screens. The generalized proxy-based estimating process is illustrated in Figure 5.1.
Selecting a Proxy
The criteria for a good proxy are as follows:
▫ The proxy size measure should closely relate to the effort required to develop
the product.
▫ The proxy content of a product should be automatically countable.
▫ The proxy should be easy to visualize at the beginning of a project.
▫ The proxy should be customizable to the needs of each project and developer.
▫ The proxy should be sensitive to implementation variations that affect development cost or effort.
These points are discussed in the following sections.
Related to Development Effort
To be useful, a proxy must have a demonstrably close relationship to the resources
required to develop the product. By estimating the relative size of the proxy, you
can accurately judge the size of the planned product. To determine the effectiveness of a potential proxy, obtain data on the products that you have developed and
5.3 Proxy-Based Estimating 71
compare the proxy values with their development times. Using the correlation
method, determine if this or some other proxy is a better predictor of product size
or development effort. If the proxy does not pass this test (|r| >= 0.7), find another
one that does. You can quickly determine this by examining the data in a scatter
plot, like that shown in Figure 3.1 (see p. 39) and in Figure 5.2. The correlation
72 Chapter 5 Software Estimating
Obtain historical
proxy data
Produce
conceptual design
Subdivide product
into proxy parts
Select the part
data
Sum to get
estimated
parts size
Estimate total
product size
Are the
parts like any in
database?
Estimate new
part’s size
Product Requirements
Size Estimate
Repeat until
the parts are
the right size.
Repeat for
all parts.
FIGURE 5.1 PROXY-BASED SIZE ESTIMATING
coefficient r is calculated by most PSP and TSP tools, but if you want to calculate
it yourself, the formula for the correlation calculation is shown in Box 3.1 in Chapter 3 (see p. 36).
Because it is possible to get very high correlations with small amounts of
data, statisticians use a significance measure to indicate the likelihood that a relationship either has predictive value or occurred by chance. The significance calculation is shown in Chapter 3 in Box 3.2 (see p. 37).
The Proxy Content Is Automatically Countable
Because estimating accuracy improves with more and better data, you will want a
lot of proxy data. This suggests that the proxy should be a physical entity that can
be precisely defined and automatically counted. If you cannot automatically count
the proxy content of a product, there is no convenient way to get the data you will
need to improve your estimating accuracy.
Easily Visualized at the Beginning of the Project
If the proxy is harder to visualize than the number of hours required to develop a
product, you may as well estimate the hours directly. The usefulness of a proxy thus
depends on the degree to which it helps you to visualize the size of the planned
product. This in turn depends on your background and preferences. There will
likely be no best proxy for all people or purposes. With suitable historical data, you
could even use several different proxies in one estimate. The multiple-regression
5.3 Proxy-Based Estimating 73
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 200 400 600 800 1000 1200
Estimated Object Size
Actual Added and Modified Size
FIGURE 5.2 PART SIZE VERSUS ACTUAL SIZE (18 PASCAL PROGRAMS)
method, usually introduced with the final PSP exercise program, can be helpful for
this purpose.
Customizable to Your Project’s Needs
Much of the difficulty people have with estimating methods results from using
data from one group to plan work by another person or group. It is important,
therefore, to use data that are relevant to your particular project. This suggests that
you build a size and resource database for each type of product you develop. If the
proxies you select are not suitable for some kinds of work, examine your data to
identify more suitable proxies. After writing several programs, you should have
enough data to identify useful proxies.
Sensitive to Implementation Variations
The proxies that are most easily visualized at the beginning of a project are application parts such as classes, inputs, outputs, database fields, forms, and reports.
However, a good development estimate requires parts that closely relate to the
product to be built and the labor to build it. This requires that proxy data be available for each implementation language, design style, and application category.
Possible Proxies
Many potential proxies could meet the criteria outlined above. The function-point
method is an obvious candidate because it is widely used. Many peo

Kết quả (Việt) 1:

Chương này chỉ là ước tính kích thước. Nó bắt đầu với một mô tả ngắn gọn khái niệm thiết kế và sau đó bao gồm ủy quyền dựa trên ước tính. Chương 6 mô tả cácThăm dò các phương pháp để sử dụng proxy để thực hiện ước tính kích thước và thời gian. Như minh hoạ trongTìm 4.1 tại chương 4 (xem trang 63), PSP kế hoạch quá trình bắt đầu với ý tưởng thiết kế. Điều này cung cấp cơ sở cho các ước tính kích thước và nguồn lực. Tại cácngay từ đầu, bạn sẽ biết tương đối ít về sản phẩm kế hoạch, vì vậy ước tính của bạnsẽ ít nhất là chính xác. Bởi vì bạn phải có lẽ là cam kết một ngày giao hàng,Tuy nhiên, bạn phải thực hiện ước lượng tốt nhất mà bạn có thể. Chöông naøy moâlàm thế nào để xác định các bộ phận của một sản phẩm kế hoạch và ước tính kích thước.Kích cỡ nhà cư 5.1 ước tính nguyên tắcVề nguyên tắc, ước tính được thực hiện bằng cách so sánh công việc kế hoạch với công việc trước đây.Nếu kế hoạch sản phẩm thành nhiều phần nhỏ hơn và so sánh từng phầndữ liệu về các bộ phận tương tự như trước khi sản phẩm, bạn có thể đánh giá kích thước của các mớisản phẩm. Chiến lược này hoạt động tốt cho ước tính gần như bất kỳ loại phát triểnlàm việc. Tuy nhiên, nó đòi hỏi các dữ liệu trên các sản phẩm bạn đã phát triển và công việccần thiết để phát triển chúng. Bạn cũng cần một phương pháp để sử dụng dữ liệu lịch sử để làm choCác ước tính.Này phân chia-và-chinh phục ước tính chiến lược có lợi thế của mở rộng.Đó là, một khi bạn đã học được để làm cho các ước tính chính xác cho các bài tập PSP,bạn có thể sử dụng các phương pháp giống hệt nhau để ước tính các công việc lớn hơn. Sự khác biệt duy nhất làrằng bạn sẽ phải phân chia công việc lớn thành nhiều phần hoặc nhận được dữ liệu trên phần lớn hơn.Trong việc quy hoạch một dự án PSP, tôi sử dụng sản phẩm thuật ngữ để chỉ mục cuối cùng được sản xuất bởi các dự án và tôi sử dụng những phần thuật ngữ để chỉ các yếu tố của một sản phẩm,bất cứ điều gì bạn có kế hoạch để gọi cho họ. Tùy thuộc vào loại phát triển, các bộ phậncó thể là hệ thống, Hệ thống phụ, thành phần, các lớp học, thủ tục, cơ sở dữ liệu, hoặcthuật ngữ bất cứ điều gì tốt nhất áp dụng cho sản phẩm cụ thể đó. Ví dụ, khi tôi ước tính một chương trình C++, các bộ phận là các lớp học. Với đối tượng Pascal, họ sẽ là các đối tượng, và với công việc cơ sở dữ liệu, họ sẽ là lĩnh vực, bàn hoặc truy vấn. Nếu cácbộ phận của sản phẩm có yếu tố nhỏ hơn, chẳng hạn như phương pháp, chức năng hoặc thủ tục, tôi gọi cho họ mục.5.2 ý tưởng thiết kếKhi lần đầu tiên thực hiện một kế hoạch để phát triển một sản phẩm, bạn thường có thể hiểu cácyêu cầu nhưng ít khác. Thách thức ước tính là sau đó để dự đoán kích thước củasản phẩm này được định nghĩa mơ hồ và thời gian cần thiết để phát triển nó. Bởi vì không có aicó thể biết trước như thế nào lớn sản phẩm kế hoạch sẽ hoặc nó sẽ mất bao lâu đểphát triển, ước tính sẽ luôn luôn là một quá trình không chắc chắn. Vì vậy, bạn cần phảisử dụng các sản phẩm tốt nhất yêu cầu và dữ liệu lịch sử, bạn có thể nhận được.Với PSP, bạn làm cho một kích thước ước tính đầu tiên và sau đó làm cho sự phát triểnước tính thời gian. Đối với dân số ước tính kích thước hợp lý chính xác hơn, nó phải được dựa trênmột khái niệm thiết kế ban đầu, và thiết kế khái niệm đó phải phản ánh cách bạn có kế hoạchto build the product. As noted in Chapter 4 (see p. 63), the conceptual design defines a preliminary design approach and names the expected product parts andtheir functions. Do not produce the complete design during planning; just postulate the parts you will need and the functions they will perform.For an accurate estimate, you must refine the conceptual design to the levelof the parts you know how to build. Next, check for historical data on similar parts.If a part does not resemble anything in your historical records, see if you have refined the conceptual design to the proper level. Assuming you have a reasonablycomplete and well-structured parts database, you will likely find that the part is acomposite of several more basic parts. If so, refine it into those more basic parts.If a conceptual part is at the right level and still does not look like any of your existing part data, estimate it as the first of a new kind of part. In doing so, comparethis part to other product parts in the database to get a feel for their relationships70 Chapter 5 Software Estimatingand then make your best intuitive estimate of its size. Then, after you have completed the development work, measure the size of the new parts and enter thesedata into your database for use in estimating future work.5.3 Proxy-Based EstimatingConsider the example of construction. In home building, the number of square feetof living space provides a basis for estimating construction costs. Few people,however, can visualize the house they want in terms of square feet. They think ofnumber of bedrooms and bathrooms. Software estimating has similar problems. Ifwe could judge the number of database relations or LOC for a product requirement, we could probably make a pretty good estimate of that product’s size. Unfortunately, few people can directly judge how many LOC or database elements itwould take to meet a product requirement.What is needed is some proxy that relates product size to the functions wecan visualize. A proxy is a substitute or a stand-in. Assuming it is easier to visualize the proxy than the size measure, the proxy can help you to judge a product’slikely size. Examples of proxies are classes, tables, fields, or screens. The generalized proxy-based estimating process is illustrated in Figure 5.1.Selecting a ProxyThe criteria for a good proxy are as follows:▫ The proxy size measure should closely relate to the effort required to developthe product.▫ The proxy content of a product should be automatically countable.▫ The proxy should be easy to visualize at the beginning of a project.▫ The proxy should be customizable to the needs of each project and developer.▫ The proxy should be sensitive to implementation variations that affect development cost or effort.These points are discussed in the following sections.Related to Development Effort
To be useful, a proxy must have a demonstrably close relationship to the resources
required to develop the product. By estimating the relative size of the proxy, you
can accurately judge the size of the planned product. To determine the effectiveness of a potential proxy, obtain data on the products that you have developed and
5.3 Proxy-Based Estimating 71
compare the proxy values with their development times. Using the correlation
method, determine if this or some other proxy is a better predictor of product size
or development effort. If the proxy does not pass this test (|r| >= 0.7), find another
one that does. You can quickly determine this by examining the data in a scatter
plot, like that shown in Figure 3.1 (see p. 39) and in Figure 5.2. The correlation
72 Chapter 5 Software Estimating
Obtain historical
proxy data
Produce
conceptual design
Subdivide product
into proxy parts
Select the part
data
Sum to get
estimated
parts size
Estimate total
product size
Are the
parts like any in
database?
Estimate new
part’s size
Product Requirements
Size Estimate
Repeat until
the parts are
the right size.
Repeat for
all parts.
FIGURE 5.1 PROXY-BASED SIZE ESTIMATING
coefficient r is calculated by most PSP and TSP tools, but if you want to calculate
it yourself, the formula for the correlation calculation is shown in Box 3.1 in Chapter 3 (see p. 36).
Because it is possible to get very high correlations with small amounts of
data, statisticians use a significance measure to indicate the likelihood that a relationship either has predictive value or occurred by chance. The significance calculation is shown in Chapter 3 in Box 3.2 (see p. 37).
The Proxy Content Is Automatically Countable
Because estimating accuracy improves with more and better data, you will want a
lot of proxy data. This suggests that the proxy should be a physical entity that can
be precisely defined and automatically counted. If you cannot automatically count
the proxy content of a product, there is no convenient way to get the data you will
need to improve your estimating accuracy.
Easily Visualized at the Beginning of the Project
If the proxy is harder to visualize than the number of hours required to develop a
product, you may as well estimate the hours directly. The usefulness of a proxy thus
depends on the degree to which it helps you to visualize the size of the planned
product. This in turn depends on your background and preferences. There will
likely be no best proxy for all people or purposes. With suitable historical data, you
could even use several different proxies in one estimate. The multiple-regression
5.3 Proxy-Based Estimating 73
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 200 400 600 800 1000 1200
Estimated Object Size
Actual Added and Modified Size
FIGURE 5.2 PART SIZE VERSUS ACTUAL SIZE (18 PASCAL PROGRAMS)
method, usually introduced with the final PSP exercise program, can be helpful for
this purpose.
Customizable to Your Project’s Needs
Much of the difficulty people have with estimating methods results from using
data from one group to plan work by another person or group. It is important,
therefore, to use data that are relevant to your particular project. This suggests that
you build a size and resource database for each type of product you develop. If the
proxies you select are not suitable for some kinds of work, examine your data to
identify more suitable proxies. After writing several programs, you should have
enough data to identify useful proxies.
Sensitive to Implementation Variations
The proxies that are most easily visualized at the beginning of a project are application parts such as classes, inputs, outputs, database fields, forms, and reports.
However, a good development estimate requires parts that closely relate to the
product to be built and the labor to build it. This requires that proxy data be available for each implementation language, design style, and application category.
Possible Proxies
Many potential proxies could meet the criteria outlined above. The function-point
method is an obvious candidate because it is widely used. Many peo

Kết quả (Việt) 2:

Địa chỉ chương kích thước ước lượng này. Nó bắt đầu với một mô tả ngắn gọn về thiết kế khái niệm và sau đó bao gồm dự toán dựa trên proxy. Chương 6 mô tả các
phương pháp PROBE để sử dụng proxy để thực hiện ước lượng kích thước và thời gian. Như thể hiện trong
hình 4.1 trong chương 4 (xem tr. 63), quá trình lập kế hoạch PSP bắt đầu với thiết kế khái niệm. Đây là cơ sở cho việc ước lượng kích thước và tài nguyên. Vào
lúc bắt đầu, bạn sẽ biết tương đối ít về các sản phẩm theo kế hoạch, vì vậy ước tính của bạn
sẽ chính xác nhất. Bởi vì bạn có lẽ phải cam kết một ngày giao hàng,
tuy nhiên, bạn phải thực hiện các ước tính tốt nhất mà bạn có thể. Chương này mô tả
làm thế nào để xác định các phần của một sản phẩm kế hoạch và ước tính kích thước của chúng.
5.1 Kích dự toán Nguyên tắc
Về nguyên tắc, dự toán được thực hiện bằng cách so sánh các công việc quy hoạch với công việc trước đây.
Bằng việc phân chia sản phẩm quy hoạch thành nhiều phần nhỏ hơn và so sánh từng phần
với dữ liệu trên các bộ phận tương tự như các sản phẩm trước đó, bạn có thể đánh giá kích thước của mới
sản phẩm. Chiến lược này hoạt động tốt để ước lượng gần như bất kỳ loại phát triển
công việc. Tuy nhiên, nó đòi hỏi dữ liệu về các sản phẩm bạn đã phát triển và các công việc
cần thiết để phát triển chúng. Bạn cũng cần một phương pháp cho việc sử dụng dữ liệu lịch sử để làm
dự toán.
Đây divide-and-conquer ước tính chiến lược có lợi thế là mở rộng quy mô.
Đó là, một khi bạn đã học được để làm cho ước lượng chính xác cho các bài tập PSP,
bạn có thể sử dụng giống hệt nhau phương pháp để ước lượng công việc lớn hơn. Sự khác biệt duy nhất là
bạn sẽ phải phân chia công việc lớn thành nhiều phần hoặc nhận dữ liệu trên phần lớn hơn.
Trong kế hoạch cho một dự án PSP, tôi sử dụng các sản phẩm hạn để tham khảo các item cuối được sản xuất bởi dự án và tôi sử dụng những phần hạn tham khảo các yếu tố của một sản phẩm,
bất cứ điều gì bạn có kế hoạch để gọi cho họ. Tùy thuộc vào loại phát triển, các bộ phận
có thể là hệ thống, hệ thống con, các thành phần, các lớp học, thủ tục, cơ sở dữ liệu, hoặc
bất cứ điều gì tốt nhất hạn áp dụng đối với sản phẩm cụ thể. Ví dụ, khi tôi ước tính một chương trình C ++, các bộ phận có các lớp học. Với Object Pascal, họ sẽ là đối tượng, và với công việc cơ sở dữ liệu, họ sẽ là các lĩnh vực, các bảng, hoặc truy vấn. Nếu các
bộ phận của sản phẩm có thành phần nhỏ hơn, chẳng hạn như các phương pháp, chức năng, hoặc thủ tục, tôi gọi họ là các mặt hàng.
5.2 Thiết kế Conceptual
Khi lần đầu tiên thực hiện một kế hoạch để phát triển một sản phẩm, bạn có thể thường hiểu được
yêu cầu nhưng ít người nào khác. Thách thức lập dự toán là sau đó để dự đoán kích thước của
sản phẩm được xác định một cách mơ hồ này và thời gian cần thiết để phát triển nó. Bởi vì không ai
có thể biết trước như thế nào lớn một sản phẩm dự kiến sẽ là bao nhiêu lâu nó sẽ làm để
phát triển, ước tính sẽ luôn luôn là một quá trình không chắc chắn. Do đó, bạn cần phải
sử dụng các yêu cầu sản phẩm tốt nhất và dữ liệu lịch sử, bạn có thể nhận được.
Với PSP, bạn thực hiện một ước tính kích thước đầu tiên và sau đó làm cho sự phát triển
ước tính thời gian. Đối với các ước tính kích thước để được hợp lý chính xác, nó phải được dựa trên
một khái niệm thiết kế ban đầu, và rằng thiết kế khái niệm phải phản ánh cách bạn có kế hoạch
để xây dựng các sản phẩm. Như đã nêu trong Chương 4 (xem trang 63.), Thiết kế khái niệm định nghĩa một phương pháp thiết kế sơ bộ và tên các bộ phận sản phẩm dự kiến và
chức năng của mình. Đừng sản xuất ra các thiết kế hoàn chỉnh trong quy hoạch; chỉ mặc nhận những phần bạn sẽ cần và các chức năng mà họ sẽ thực hiện.
Đối với một ước tính chính xác, bạn phải tinh chỉnh các thiết kế ý tưởng đến mức độ
của những phần bạn biết làm thế nào để xây dựng. Tiếp theo, kiểm tra các dữ liệu lịch sử về các bộ phận tương tự.
Nếu một phần không giống với bất cứ điều gì trong hồ sơ lịch sử của bạn, xem bạn đã tinh chế các thiết kế khái niệm đến mức thích hợp. Giả sử bạn có một lý
cơ sở dữ liệu các bộ phận hoàn chỉnh và có cấu trúc tốt, có thể bạn sẽ tìm thấy rằng một phần là một
hỗn hợp của một số bộ phận cơ bản hơn. Nếu vậy, tinh chỉnh nó thành những phần cơ bản hơn.
Nếu một phần khái niệm là ở mức độ phải và vẫn không giống như bất kỳ một phần của dữ liệu hiện có của bạn, ước tính nó như là đầu tiên của một loại mới của phần. Khi làm như vậy, so sánh
phần này đến các bộ phận sản phẩm khác trong cơ sở dữ liệu để có được một cảm giác về mối quan hệ của họ
70 Chương 5 Phần mềm dự toán
và sau đó thực hiện ước tính trực quan của bạn tốt nhất của kích thước của nó. Sau đó, sau khi bạn đã hoàn tất các công việc phát triển, đo kích thước của các bộ phận mới và nhập các
dữ liệu vào cơ sở dữ liệu của bạn để sử dụng trong ước lượng công việc tương lai.
5.3 Proxy-Based dự toán
xem xét các ví dụ về xây dựng. Trong tòa nhà, số feet vuông
của không gian sống cung cấp một cơ sở cho việc lập dự toán chi phí xây dựng. Rất ít người,
tuy nhiên, có thể hình dung ngôi nhà họ muốn về feet vuông. Họ nghĩ về
số lượng phòng ngủ và phòng tắm. Phần mềm dự toán có vấn đề tương tự. Nếu
chúng ta có thể phán xét ​​số lượng các mối quan hệ cơ sở dữ liệu hoặc LỘC cho một yêu cầu sản phẩm, chúng tôi có thể có thể làm cho một ước lượng khá tốt về kích thước của sản phẩm đó. Thật không may, rất ít người có thể trực tiếp đánh giá bao nhiêu LOC hoặc các yếu tố cơ sở dữ liệu nó
sẽ làm để đáp ứng một yêu cầu sản phẩm.
Vài proxy liên quan kích thước sản phẩm đến các chức năng chúng tôi Điều cần thiết là
có thể hình dung. Một proxy là một thay thế hoặc một stand-in. Giả sử nó là dễ dàng hơn để hình dung các proxy hơn thước đo kích thước, các proxy có thể giúp bạn đánh giá một sản phẩm
có khả năng kích thước. Ví dụ về các proxy là các lớp học, bảng, các lĩnh vực, hoặc màn hình. Quá trình ước lượng dựa trên proxy tổng quát được minh họa trong hình 5.1.
Lựa chọn một Proxy
các tiêu chí cho một proxy tốt như sau:
▫ Các biện pháp kích thước proxy nên liên quan chặt chẽ đến các nỗ lực cần thiết để phát
triển. Sản phẩm
▫ Các nội dung ủy quyền của một sản phẩm nên được tự động đếm được.
▫ Các proxy sẽ được dễ dàng để hình dung ở đầu của một dự án.
▫ Các proxy nên được tùy biến theo nhu cầu của từng dự án và phát triển.
▫ Các proxy nên nhạy cảm với các biến thể thực hiện điều đó ảnh hưởng đến chi phí phát triển và nỗ lực .
Những điểm này sẽ được thảo luận trong các phần sau.
liên quan đến nỗ lực phát triển
Để có ích, một proxy phải có một mối quan hệ ràng minh gần các nguồn lực
cần thiết để phát triển sản phẩm. Bằng cách ước lượng kích thước tương đối của các proxy, bạn
có thể đánh giá chính xác kích thước của sản phẩm theo kế hoạch. Để xác định hiệu quả của một proxy tiềm năng, thu thập số liệu về các sản phẩm mà bạn đã phát triển và
5.3 Proxy-Dựa Ước tính 71
so sánh các giá trị proxy với thời gian phát triển của họ. Sử dụng sự tương quan
phương pháp, xác định nếu điều này hoặc một vài proxy khác là một yếu tố dự báo tốt hơn về kích thước sản phẩm
hoặc nỗ lực phát triển. Nếu proxy không vượt qua bài kiểm tra này (| r |> = 0,7), tìm thấy một
một trong đó không. Bạn có thể nhanh chóng xác định điều này bằng cách kiểm tra các dữ liệu trong một phân tán
cốt truyện, giống như những gì thể hiện trong hình 3.1 (xem tr. 39) và trong hình 5.2. Sự tương quan
72 Chương 5 Phần mềm Ước
Lấy lịch sử
dữ liệu proxy
Sản xuất
khái niệm thiết kế
sản phẩm chia
thành các phần Proxy
Chọn phần
dữ liệu
Sum để có được
ước tính
các bộ phận kích thước
Ước tính tổng
sản phẩm kích thước
là các
bộ phận như bất kỳ trong
cơ sở dữ liệu?
Ước mới
kích thước một phần của
yêu cầu sản phẩm
Kích Ước tính
Lặp lại cho đến
các bộ phận có
kích thước đúng.
Lặp lại cho
tất cả các bộ phận.
HÌNH 5.1 PROXY DỰA TRÊN SIZE ước lượng
hệ số r được tính bởi hầu hết các PSP và TSP công cụ, nhưng nếu bạn muốn tính toán
đó cho mình, các công thức để tính toán tương quan được thể hiện trong Box 3.1 ở Chương 3 (xem tr. 36).
Bởi vì nó có thể để có được mối tương quan rất cao với một lượng nhỏ
dữ liệu, thống kê sử dụng một biện pháp quan trọng để chỉ ra khả năng rằng một mối quan hệ, hoặc có giá trị tiên đoán hoặc đã xảy ra một cách tình cờ. Việc tính toán có ý nghĩa được thể hiện trong Chương 3 trong Box 3.2 (xem tr. 37).
Nội dung Proxy là Tự động đếm
Bởi vì ước lượng chính xác được cải thiện với nhiều dữ liệu hơn và tốt hơn, bạn sẽ muốn có một
rất nhiều dữ liệu proxy. Điều này cho thấy rằng các proxy phải là một thực thể vật lý có thể
được định nghĩa một cách chính xác và tự động tính. Nếu bạn không thể tự động đếm
các nội dung ủy quyền của một sản phẩm, không có cách nào thuận tiện để có được các dữ liệu bạn sẽ
cần phải cải thiện độ chính xác ước tính của bạn.
Dễ dàng được nhìn vào lúc bắt đầu của dự án
nếu các proxy là khó để hình dung hơn số giờ cần thiết để phát triển một
sản phẩm, bạn cũng có thể ước tính số giờ trực tiếp. Sự hữu dụng của một proxy do đó
phụ thuộc vào mức độ mà nó giúp bạn hình dung kích thước của các kế hoạch
sản phẩm. Điều này lại phụ thuộc vào bối cảnh và sở thích của bạn. Sẽ
có khả năng là không có proxy tốt nhất cho tất cả mọi người hoặc các mục đích. Với dữ liệu lịch sử phù hợp, bạn
thậm chí có thể sử dụng proxy khác nhau ở một ước tính. Các đa hồi quy
5.3 Proxy-Dựa Ước tính 73
0
200
400
600
800
1000
1200
1400
1600
1800
2000
0 200 400 600 800 1000 1200
Ước tính Object Kích thước
thực tế gia tăng và thay đổi kích thước
hình 5.2 PHẦN SIZE SO VỚI SIZE THỰC TẾ (18 PASCAL CHƯƠNG TRÌNH)
phương pháp, thường được giới thiệu với các chương trình tập luyện PSP thức, có thể hữu ích cho
mục đích này.
Tùy chỉnh cho nhu cầu dự án của bạn của
Phần lớn những khó khăn người có với tính toán phương pháp kết quả từ việc sử dụng
dữ liệu từ một nhóm để lên kế hoạch làm việc của cá nhân hay một nhóm khác. Nó là quan trọng,
do đó, để sử dụng dữ liệu có liên quan đến dự án cụ thể của bạn. Điều này cho thấy rằng
bạn xây dựng một cơ sở dữ liệu tài nguyên và kích thước cho từng loại sản phẩm bạn phát triển. Nếu
proxy bạn chọn không thích hợp đối với một số loại công việc, kiểm tra dữ liệu của bạn để
xác định các proxy phù hợp hơn. Sau khi viết một số chương trình, bạn cần phải có
đủ dữ liệu để xác định các proxy hữu ích.
Nhạy cảm với Biến thể thực hiện
Các proxy được dễ dàng nhất hình dung ở đầu của một dự án là một phần ứng dụng như lớp học, đầu vào, đầu ra, các lĩnh vực cơ sở dữ liệu, biểu mẫu, và các báo cáo .
Tuy nhiên, một ước tính phát triển tốt đòi hỏi các bộ phận có liên quan chặt chẽ với các
sản phẩm được xây dựng và lao động để xây dựng nó. Điều này đòi hỏi dữ liệu proxy có sẵn cho mỗi ngôn ngữ thực hiện, phong cách thiết kế, và loại ứng dụng.
Proxies thể
Nhiều proxy tiềm năng có thể đáp ứng các tiêu chí nêu trên. Các chức năng điểm
phương pháp là một ứng cử viên rõ ràng bởi vì nó được sử dụng rộng rãi. Nhiều peo