- Văn bản
- Lịch sử
On the other hand, you could count
On the other hand, you could count selected keywords and functions such as
if, then, else, begin, end, and assignment (:=). Your count in this case would be
nine. Although the choice is arbitrary, you must be explicit and consistent.
For my work, I have adopted the following simple guideline:
▫ Count logical statements such as, for example, every semicolon and selected
keywords.
▫ Write every countable statement on a separate line.
▫ Count all statements except blank and comment lines.
▫ Count each language separately.
These guidelines produce open and clean-looking code that looks like the
preceding nine-line example. It also simplifies automatic LOC counting. Blanks
and comment lines are not counted because the number of logical program statements generally determines the development effort. If, however, you find that the
time required to write comments is significant, then you could decide to count
3.3 Establishing a Line-of-Code Counting Standard 41
them. The way to decide this would be to measure size with and without counting comment lines to determine which provides a higher correlation with development time.
3.4 Size Accounting
Even after selecting the size-measurement definition, there are many ways to use
the measures. This is particularly true when you work on a development team that
produces multiple versions of large legacy products. To track all of the program
changes and additions and to gather the data you need for estimating, you must use
a size accounting system.
Although size seems like a simple concept, size measures can be hard to track
if they are not properly defined and used. For example, if you started with a 1,000-
LOC program and added 100 LOC, the result would be 1,100 LOC. If you merely
wrote a new 100-LOC program, however, the result would be a 100-LOC program. Although this result seems obvious and the development effort would probably be roughly comparable, the sizes of the resulting products are vastly different.
Size accounting will help you to understand and properly use size data. The basic
program elements in the size accounting system are as follows:
▫ Base: This is the measure of the initial unmodified base program to which
subsequent enhancements are added. For a new program, the base size would
be zero.
▫ Added: This is the new code that is added to the base. Again, for a new program, the base size would be zero and the added code would be all the code.
▫ Modified: The modified code is that part of the base code that is changed.
▫ Deleted: The deleted code is that part of the base code that is removed and
not used in the next program or program version.
▫ Reused: When an existing program or program routine is copied from
some library or otherwise included in a new program, it is counted as reused
code only if it is unmodified. If it is even slightly modified, the size of this included program is included in the base size and the changes are counted as
modifications.
▫ Added and Modified: For many kinds of software development work, the effort required to write a new LOC is roughly comparable to the effort required
to modify an existing LOC. In these cases, it is convenient to combine the
Added size measures and Modified size measures into an “Added and Modified” size measure. This is the measure generally used in the PSP exercises for
estimating development effort and for measuring and managing quality.
42 Chapter 3 Measuring Software Size
▫ New Reusable: A common development strategy is to build a library of commonly used functions and to reuse them whenever they are subsequently
needed. Because this strategy can save a great deal of effort, the PSP includes
a New Reusable size measure for the newly developed code that is planned
for inclusion in the reuse library. If you rework base code to be reusable, also
mark it with an asterisk.
▫ Total: Total program size measures the entire program, regardless of how its
parts were produced.
The reason to track program additions, deletions, and modifications is illustrated in Figure 3.3. Starting with version 0, which has a counted size of 350 LOC,
you add or modify 125 LOC. Thus, you expect to have a finished version 1 of 475
LOC. When you measure version 1, however, its total size is only 450 LOC.
Where did the 25 LOC go?
This can best be explained by using the size accounting format shown in
Table 3.2. Here, starting with a new program base of zero LOC, you develop 350
new LOC, for a total of 350 LOC in version 0. This 350 LOC is the base on which
you develop version 1. In developing version 1, you add 100 LOC and modify 25
LOC of the V1 base. The 125 LOC is thus made up of 100 LOC new and 25 LOC
modified. Notice, however, that the 100 LOC are shown only in the Added column
on the left of Table 3.2, but the 25 LOC are shown in both the Added and Subtracted
columns. The reason is that a modified LOC must be counted as a one-line addition
and a one-line deletion. This is because that line is already counted in the base. If
you don’t subtract the 25, you will double-count it. Version 1 (or version 2 base)
now is shown to contain 450 LOC, just as the counter indicated.
if, then, else, begin, end, and assignment (:=). Your count in this case would be
nine. Although the choice is arbitrary, you must be explicit and consistent.
For my work, I have adopted the following simple guideline:
▫ Count logical statements such as, for example, every semicolon and selected
keywords.
▫ Write every countable statement on a separate line.
▫ Count all statements except blank and comment lines.
▫ Count each language separately.
These guidelines produce open and clean-looking code that looks like the
preceding nine-line example. It also simplifies automatic LOC counting. Blanks
and comment lines are not counted because the number of logical program statements generally determines the development effort. If, however, you find that the
time required to write comments is significant, then you could decide to count
3.3 Establishing a Line-of-Code Counting Standard 41
them. The way to decide this would be to measure size with and without counting comment lines to determine which provides a higher correlation with development time.
3.4 Size Accounting
Even after selecting the size-measurement definition, there are many ways to use
the measures. This is particularly true when you work on a development team that
produces multiple versions of large legacy products. To track all of the program
changes and additions and to gather the data you need for estimating, you must use
a size accounting system.
Although size seems like a simple concept, size measures can be hard to track
if they are not properly defined and used. For example, if you started with a 1,000-
LOC program and added 100 LOC, the result would be 1,100 LOC. If you merely
wrote a new 100-LOC program, however, the result would be a 100-LOC program. Although this result seems obvious and the development effort would probably be roughly comparable, the sizes of the resulting products are vastly different.
Size accounting will help you to understand and properly use size data. The basic
program elements in the size accounting system are as follows:
▫ Base: This is the measure of the initial unmodified base program to which
subsequent enhancements are added. For a new program, the base size would
be zero.
▫ Added: This is the new code that is added to the base. Again, for a new program, the base size would be zero and the added code would be all the code.
▫ Modified: The modified code is that part of the base code that is changed.
▫ Deleted: The deleted code is that part of the base code that is removed and
not used in the next program or program version.
▫ Reused: When an existing program or program routine is copied from
some library or otherwise included in a new program, it is counted as reused
code only if it is unmodified. If it is even slightly modified, the size of this included program is included in the base size and the changes are counted as
modifications.
▫ Added and Modified: For many kinds of software development work, the effort required to write a new LOC is roughly comparable to the effort required
to modify an existing LOC. In these cases, it is convenient to combine the
Added size measures and Modified size measures into an “Added and Modified” size measure. This is the measure generally used in the PSP exercises for
estimating development effort and for measuring and managing quality.
42 Chapter 3 Measuring Software Size
▫ New Reusable: A common development strategy is to build a library of commonly used functions and to reuse them whenever they are subsequently
needed. Because this strategy can save a great deal of effort, the PSP includes
a New Reusable size measure for the newly developed code that is planned
for inclusion in the reuse library. If you rework base code to be reusable, also
mark it with an asterisk.
▫ Total: Total program size measures the entire program, regardless of how its
parts were produced.
The reason to track program additions, deletions, and modifications is illustrated in Figure 3.3. Starting with version 0, which has a counted size of 350 LOC,
you add or modify 125 LOC. Thus, you expect to have a finished version 1 of 475
LOC. When you measure version 1, however, its total size is only 450 LOC.
Where did the 25 LOC go?
This can best be explained by using the size accounting format shown in
Table 3.2. Here, starting with a new program base of zero LOC, you develop 350
new LOC, for a total of 350 LOC in version 0. This 350 LOC is the base on which
you develop version 1. In developing version 1, you add 100 LOC and modify 25
LOC of the V1 base. The 125 LOC is thus made up of 100 LOC new and 25 LOC
modified. Notice, however, that the 100 LOC are shown only in the Added column
on the left of Table 3.2, but the 25 LOC are shown in both the Added and Subtracted
columns. The reason is that a modified LOC must be counted as a one-line addition
and a one-line deletion. This is because that line is already counted in the base. If
you don’t subtract the 25, you will double-count it. Version 1 (or version 2 base)
now is shown to contain 450 LOC, just as the counter indicated.
0/5000
On the other hand, you could count selected keywords and functions such asif, then, else, begin, end, and assignment (:=). Your count in this case would benine. Although the choice is arbitrary, you must be explicit and consistent.For my work, I have adopted the following simple guideline:▫ Count logical statements such as, for example, every semicolon and selectedkeywords.▫ Write every countable statement on a separate line.▫ Count all statements except blank and comment lines.▫ Count each language separately.These guidelines produce open and clean-looking code that looks like thepreceding nine-line example. It also simplifies automatic LOC counting. Blanksand comment lines are not counted because the number of logical program statements generally determines the development effort. If, however, you find that thetime required to write comments is significant, then you could decide to count3.3 Establishing a Line-of-Code Counting Standard 41them. The way to decide this would be to measure size with and without counting comment lines to determine which provides a higher correlation with development time.3.4 Size AccountingEven after selecting the size-measurement definition, there are many ways to usethe measures. This is particularly true when you work on a development team thatproduces multiple versions of large legacy products. To track all of the programchanges and additions and to gather the data you need for estimating, you must usea size accounting system.
Although size seems like a simple concept, size measures can be hard to track
if they are not properly defined and used. For example, if you started with a 1,000-
LOC program and added 100 LOC, the result would be 1,100 LOC. If you merely
wrote a new 100-LOC program, however, the result would be a 100-LOC program. Although this result seems obvious and the development effort would probably be roughly comparable, the sizes of the resulting products are vastly different.
Size accounting will help you to understand and properly use size data. The basic
program elements in the size accounting system are as follows:
▫ Base: This is the measure of the initial unmodified base program to which
subsequent enhancements are added. For a new program, the base size would
be zero.
▫ Added: This is the new code that is added to the base. Again, for a new program, the base size would be zero and the added code would be all the code.
▫ Modified: The modified code is that part of the base code that is changed.
▫ Deleted: The deleted code is that part of the base code that is removed and
not used in the next program or program version.
▫ Reused: When an existing program or program routine is copied from
some library or otherwise included in a new program, it is counted as reused
code only if it is unmodified. If it is even slightly modified, the size of this included program is included in the base size and the changes are counted as
modifications.
▫ Added and Modified: For many kinds of software development work, the effort required to write a new LOC is roughly comparable to the effort required
to modify an existing LOC. In these cases, it is convenient to combine the
Added size measures and Modified size measures into an “Added and Modified” size measure. This is the measure generally used in the PSP exercises for
estimating development effort and for measuring and managing quality.
42 Chapter 3 Measuring Software Size
▫ New Reusable: A common development strategy is to build a library of commonly used functions and to reuse them whenever they are subsequently
needed. Because this strategy can save a great deal of effort, the PSP includes
a New Reusable size measure for the newly developed code that is planned
for inclusion in the reuse library. If you rework base code to be reusable, also
mark it with an asterisk.
▫ Total: Total program size measures the entire program, regardless of how its
parts were produced.
The reason to track program additions, deletions, and modifications is illustrated in Figure 3.3. Starting with version 0, which has a counted size of 350 LOC,
you add or modify 125 LOC. Thus, you expect to have a finished version 1 of 475
LOC. When you measure version 1, however, its total size is only 450 LOC.
Where did the 25 LOC go?
This can best be explained by using the size accounting format shown in
Table 3.2. Here, starting with a new program base of zero LOC, you develop 350
new LOC, for a total of 350 LOC in version 0. This 350 LOC is the base on which
you develop version 1. In developing version 1, you add 100 LOC and modify 25
LOC of the V1 base. The 125 LOC is thus made up of 100 LOC new and 25 LOC
modified. Notice, however, that the 100 LOC are shown only in the Added column
on the left of Table 3.2, but the 25 LOC are shown in both the Added and Subtracted
columns. The reason is that a modified LOC must be counted as a one-line addition
and a one-line deletion. This is because that line is already counted in the base. If
you don’t subtract the 25, you will double-count it. Version 1 (or version 2 base)
now is shown to contain 450 LOC, just as the counter indicated.
Although size seems like a simple concept, size measures can be hard to track
if they are not properly defined and used. For example, if you started with a 1,000-
LOC program and added 100 LOC, the result would be 1,100 LOC. If you merely
wrote a new 100-LOC program, however, the result would be a 100-LOC program. Although this result seems obvious and the development effort would probably be roughly comparable, the sizes of the resulting products are vastly different.
Size accounting will help you to understand and properly use size data. The basic
program elements in the size accounting system are as follows:
▫ Base: This is the measure of the initial unmodified base program to which
subsequent enhancements are added. For a new program, the base size would
be zero.
▫ Added: This is the new code that is added to the base. Again, for a new program, the base size would be zero and the added code would be all the code.
▫ Modified: The modified code is that part of the base code that is changed.
▫ Deleted: The deleted code is that part of the base code that is removed and
not used in the next program or program version.
▫ Reused: When an existing program or program routine is copied from
some library or otherwise included in a new program, it is counted as reused
code only if it is unmodified. If it is even slightly modified, the size of this included program is included in the base size and the changes are counted as
modifications.
▫ Added and Modified: For many kinds of software development work, the effort required to write a new LOC is roughly comparable to the effort required
to modify an existing LOC. In these cases, it is convenient to combine the
Added size measures and Modified size measures into an “Added and Modified” size measure. This is the measure generally used in the PSP exercises for
estimating development effort and for measuring and managing quality.
42 Chapter 3 Measuring Software Size
▫ New Reusable: A common development strategy is to build a library of commonly used functions and to reuse them whenever they are subsequently
needed. Because this strategy can save a great deal of effort, the PSP includes
a New Reusable size measure for the newly developed code that is planned
for inclusion in the reuse library. If you rework base code to be reusable, also
mark it with an asterisk.
▫ Total: Total program size measures the entire program, regardless of how its
parts were produced.
The reason to track program additions, deletions, and modifications is illustrated in Figure 3.3. Starting with version 0, which has a counted size of 350 LOC,
you add or modify 125 LOC. Thus, you expect to have a finished version 1 of 475
LOC. When you measure version 1, however, its total size is only 450 LOC.
Where did the 25 LOC go?
This can best be explained by using the size accounting format shown in
Table 3.2. Here, starting with a new program base of zero LOC, you develop 350
new LOC, for a total of 350 LOC in version 0. This 350 LOC is the base on which
you develop version 1. In developing version 1, you add 100 LOC and modify 25
LOC of the V1 base. The 125 LOC is thus made up of 100 LOC new and 25 LOC
modified. Notice, however, that the 100 LOC are shown only in the Added column
on the left of Table 3.2, but the 25 LOC are shown in both the Added and Subtracted
columns. The reason is that a modified LOC must be counted as a one-line addition
and a one-line deletion. This is because that line is already counted in the base. If
you don’t subtract the 25, you will double-count it. Version 1 (or version 2 base)
now is shown to contain 450 LOC, just as the counter indicated.
đang được dịch, vui lòng đợi..
Mặt khác, bạn có thể đếm được chọn từ khoá và các chức năng như
nếu, sau đó, người nào khác, bắt đầu, kết thúc, và gán (: =). Tính của bạn trong trường hợp này sẽ là
chín. Mặc dù sự lựa chọn là tùy ý, bạn phải rõ ràng và nhất quán.
Đối với công việc của tôi, tôi đã áp dụng các hướng dẫn đơn giản sau:
▫ Đếm báo cáo logic chẳng hạn như, ví dụ, mỗi dấu chấm phẩy và được lựa chọn
từ khóa.
▫ Viết mỗi câu đếm được trên một dòng riêng biệt .
▫ Đếm tất cả các báo cáo ngoại trừ dòng trống và nhận xét.
▫ Đếm từng ngôn ngữ riêng.
Những nguyên tắc sản xuất mã mở và sạch sẽ trông giống như
Ví dụ trước chín dòng. Nó cũng giúp đơn giản đếm LỘC tự động. Blanks
và dòng chú thích không được tính vì số lượng các báo cáo chương trình logic thường xác định các nỗ lực phát triển. Tuy nhiên, nếu bạn thấy rằng
thời gian cần thiết để bình luận là quan trọng, sau đó bạn có thể quyết định để đếm
3.3 Thiết lập một Line-of-Code Đếm chuẩn 41
họ. Các cách để quyết định này sẽ được đo kích thước có và không đếm dòng bình luận để xác định cung cấp một sự tương quan cao với thời gian phát triển.
3.4 Kích Kế toán
Ngay cả sau khi chọn định nghĩa kích thước đo lường, có rất nhiều cách để sử dụng
các biện pháp. Điều này đặc biệt đúng khi bạn làm việc trên một nhóm phát triển
sản xuất nhiều phiên bản của sản phẩm di sản lớn. Để theo dõi tất cả các chương trình
thay đổi và bổ sung và để thu thập các dữ liệu bạn cần cho việc ước tính, bạn phải sử dụng
một hệ thống kích thước kế toán.
Mặc dù kích thước có vẻ giống như một khái niệm đơn giản, các biện pháp kích thước có thể được khó khăn để theo dõi
nếu họ không được định nghĩa và sử dụng đúng . Ví dụ, nếu bạn bắt đầu với một 1,000-
chương trình LOC và thêm 100 LOC, kết quả sẽ là 1.100 LỘC. Nếu bạn chỉ đơn thuần là
viết một chương trình 100-LỘC mới, tuy nhiên, kết quả sẽ là một chương trình 100-LỘC. Mặc dù kết quả này có vẻ rõ ràng và nỗ lực phát triển có lẽ sẽ có thể so sánh, các kích thước của sản phẩm thu được là rất khác nhau.
Kích kế toán sẽ giúp các bạn hiểu và sử dụng đúng kích thước dữ liệu. Các cơ bản
yếu tố chương trình trong hệ thống kế toán kích thước như sau:
▫ Base: Đây là biện pháp của các chương trình cơ sở chưa sửa đổi ban đầu để mà
cải tiến tiếp theo được thêm vào. Đối với một chương trình mới, kích thước cơ sở sẽ
là zero.
▫ Added: Đây là mã mới được bổ sung vào cơ sở. Một lần nữa, trong một chương trình mới, kích thước cơ sở sẽ là zero và các mã được thêm vào sẽ là tất cả các mã.
▫ Modified: Các mã sửa đổi là một phần của cơ sở mã được thay đổi.
▫ Deleted: Mã xóa là một phần của các mã cơ sở đó là gỡ bỏ và
không được sử dụng trong các chương trình hoặc chương trình phiên bản tiếp theo.
▫ Tái sử dụng: Khi một chương trình hay chương trình thường lệ hiện tại là sao chép từ
một số thư viện hoặc đưa vào một chương trình mới, nó được tính là tái sử dụng
mã chỉ khi nó là chưa sửa đổi. Nếu nó được thậm chí một chút thay đổi, kích thước của chương trình bao gồm này được bao gồm trong các kích thước cơ bản và các thay đổi được tính là
thay đổi.
▫ gia tăng và thay đổi: Đối với nhiều loại phần mềm công việc phát triển, các nỗ lực cần thiết để viết một LỘC mới là khoảng so sánh với các nỗ lực cần thiết
để sửa đổi một LOC hiện. Trong những trường hợp này, nó là thuận tiện để kết hợp các
biện pháp kích thước thêm và các biện pháp kích thước thay đổi thành một "gia tăng và thay đổi" kích thước đo. Đây là biện pháp thường được sử dụng trong các bài tập PSP cho
ước lượng nỗ lực phát triển và để đo lường và quản lý chất lượng.
42 Chương Software 3 Đo Kích
▫ New Reusable: Một chiến lược phát triển chung là xây dựng một thư viện các chức năng thường được sử dụng và tái sử dụng chúng bất cứ khi nào họ sau đó được
cần thiết. Bởi vì chiến lược này có thể tiết kiệm rất nhiều nỗ lực, PSP bao gồm
một thước đo kích thước Reusable mới cho các mã mới được phát triển đó là lên kế hoạch
để đưa vào thư viện tái sử dụng. Nếu bạn làm lại mã cơ sở để có thể tái sử dụng, cũng
đánh dấu nó bằng một dấu sao.
▫ Total: Tổng kích thước chương trình đo lường toàn bộ chương trình, bất kể như thế nào của
các bộ phận được sản xuất.
Lý do để theo dõi bổ sung chương trình, xóa, và thay đổi được minh họa trong hình 3.3. Bắt đầu với phiên bản 0, trong đó có một kích thước tính của 350 LOC,
bạn thêm hoặc sửa đổi 125 LOC. Vì vậy, bạn mong muốn có một phiên bản kết thúc 1 của 475
LOC. Khi bạn đo phiên bản 1, tuy nhiên, tổng kích thước của nó chỉ là 450 LOC.
Đã 25 LOC đi đâu?
Điều này tốt nhất có thể được giải thích bằng cách sử dụng các định dạng kích thước kế toán trình bày trong
Bảng 3.2. Ở đây, bắt đầu với một cơ sở chương trình mới của zero LOC, bạn phát triển 350
LOC mới, với tổng số 350 LOC trong phiên bản 0. 350 LỘC Đây là cơ sở mà trên đó
bạn phát triển phiên bản 1. Trong việc phát triển phiên bản 1, bạn thêm 100 LỘC và sửa đổi 25
LOC của các cơ sở V1. Do đó 125 LOC được tạo thành từ 100 LOC mới và 25 LOC
sửa đổi. Thông báo, tuy nhiên, các LỘC 100 chỉ được hiển thị trong cột gia tăng
trên bên trái của bảng 3.2, nhưng 25 LOC được thể hiện trong cả hai thêm vào và trừ
các cột. Lý do là một LỘC sửa đổi phải được tính là một bổ sung một dòng
và một xóa một dòng. Điều này là do dòng mà đã được tính trong cơ sở. Nếu
bạn không trừ đi 25, bạn sẽ đôi đếm nó. Phiên bản 1 (hoặc phiên bản 2 cơ sở)
đã được thể hiện để chứa 450 LOC, chỉ là phản chỉ định.
nếu, sau đó, người nào khác, bắt đầu, kết thúc, và gán (: =). Tính của bạn trong trường hợp này sẽ là
chín. Mặc dù sự lựa chọn là tùy ý, bạn phải rõ ràng và nhất quán.
Đối với công việc của tôi, tôi đã áp dụng các hướng dẫn đơn giản sau:
▫ Đếm báo cáo logic chẳng hạn như, ví dụ, mỗi dấu chấm phẩy và được lựa chọn
từ khóa.
▫ Viết mỗi câu đếm được trên một dòng riêng biệt .
▫ Đếm tất cả các báo cáo ngoại trừ dòng trống và nhận xét.
▫ Đếm từng ngôn ngữ riêng.
Những nguyên tắc sản xuất mã mở và sạch sẽ trông giống như
Ví dụ trước chín dòng. Nó cũng giúp đơn giản đếm LỘC tự động. Blanks
và dòng chú thích không được tính vì số lượng các báo cáo chương trình logic thường xác định các nỗ lực phát triển. Tuy nhiên, nếu bạn thấy rằng
thời gian cần thiết để bình luận là quan trọng, sau đó bạn có thể quyết định để đếm
3.3 Thiết lập một Line-of-Code Đếm chuẩn 41
họ. Các cách để quyết định này sẽ được đo kích thước có và không đếm dòng bình luận để xác định cung cấp một sự tương quan cao với thời gian phát triển.
3.4 Kích Kế toán
Ngay cả sau khi chọn định nghĩa kích thước đo lường, có rất nhiều cách để sử dụng
các biện pháp. Điều này đặc biệt đúng khi bạn làm việc trên một nhóm phát triển
sản xuất nhiều phiên bản của sản phẩm di sản lớn. Để theo dõi tất cả các chương trình
thay đổi và bổ sung và để thu thập các dữ liệu bạn cần cho việc ước tính, bạn phải sử dụng
một hệ thống kích thước kế toán.
Mặc dù kích thước có vẻ giống như một khái niệm đơn giản, các biện pháp kích thước có thể được khó khăn để theo dõi
nếu họ không được định nghĩa và sử dụng đúng . Ví dụ, nếu bạn bắt đầu với một 1,000-
chương trình LOC và thêm 100 LOC, kết quả sẽ là 1.100 LỘC. Nếu bạn chỉ đơn thuần là
viết một chương trình 100-LỘC mới, tuy nhiên, kết quả sẽ là một chương trình 100-LỘC. Mặc dù kết quả này có vẻ rõ ràng và nỗ lực phát triển có lẽ sẽ có thể so sánh, các kích thước của sản phẩm thu được là rất khác nhau.
Kích kế toán sẽ giúp các bạn hiểu và sử dụng đúng kích thước dữ liệu. Các cơ bản
yếu tố chương trình trong hệ thống kế toán kích thước như sau:
▫ Base: Đây là biện pháp của các chương trình cơ sở chưa sửa đổi ban đầu để mà
cải tiến tiếp theo được thêm vào. Đối với một chương trình mới, kích thước cơ sở sẽ
là zero.
▫ Added: Đây là mã mới được bổ sung vào cơ sở. Một lần nữa, trong một chương trình mới, kích thước cơ sở sẽ là zero và các mã được thêm vào sẽ là tất cả các mã.
▫ Modified: Các mã sửa đổi là một phần của cơ sở mã được thay đổi.
▫ Deleted: Mã xóa là một phần của các mã cơ sở đó là gỡ bỏ và
không được sử dụng trong các chương trình hoặc chương trình phiên bản tiếp theo.
▫ Tái sử dụng: Khi một chương trình hay chương trình thường lệ hiện tại là sao chép từ
một số thư viện hoặc đưa vào một chương trình mới, nó được tính là tái sử dụng
mã chỉ khi nó là chưa sửa đổi. Nếu nó được thậm chí một chút thay đổi, kích thước của chương trình bao gồm này được bao gồm trong các kích thước cơ bản và các thay đổi được tính là
thay đổi.
▫ gia tăng và thay đổi: Đối với nhiều loại phần mềm công việc phát triển, các nỗ lực cần thiết để viết một LỘC mới là khoảng so sánh với các nỗ lực cần thiết
để sửa đổi một LOC hiện. Trong những trường hợp này, nó là thuận tiện để kết hợp các
biện pháp kích thước thêm và các biện pháp kích thước thay đổi thành một "gia tăng và thay đổi" kích thước đo. Đây là biện pháp thường được sử dụng trong các bài tập PSP cho
ước lượng nỗ lực phát triển và để đo lường và quản lý chất lượng.
42 Chương Software 3 Đo Kích
▫ New Reusable: Một chiến lược phát triển chung là xây dựng một thư viện các chức năng thường được sử dụng và tái sử dụng chúng bất cứ khi nào họ sau đó được
cần thiết. Bởi vì chiến lược này có thể tiết kiệm rất nhiều nỗ lực, PSP bao gồm
một thước đo kích thước Reusable mới cho các mã mới được phát triển đó là lên kế hoạch
để đưa vào thư viện tái sử dụng. Nếu bạn làm lại mã cơ sở để có thể tái sử dụng, cũng
đánh dấu nó bằng một dấu sao.
▫ Total: Tổng kích thước chương trình đo lường toàn bộ chương trình, bất kể như thế nào của
các bộ phận được sản xuất.
Lý do để theo dõi bổ sung chương trình, xóa, và thay đổi được minh họa trong hình 3.3. Bắt đầu với phiên bản 0, trong đó có một kích thước tính của 350 LOC,
bạn thêm hoặc sửa đổi 125 LOC. Vì vậy, bạn mong muốn có một phiên bản kết thúc 1 của 475
LOC. Khi bạn đo phiên bản 1, tuy nhiên, tổng kích thước của nó chỉ là 450 LOC.
Đã 25 LOC đi đâu?
Điều này tốt nhất có thể được giải thích bằng cách sử dụng các định dạng kích thước kế toán trình bày trong
Bảng 3.2. Ở đây, bắt đầu với một cơ sở chương trình mới của zero LOC, bạn phát triển 350
LOC mới, với tổng số 350 LOC trong phiên bản 0. 350 LỘC Đây là cơ sở mà trên đó
bạn phát triển phiên bản 1. Trong việc phát triển phiên bản 1, bạn thêm 100 LỘC và sửa đổi 25
LOC của các cơ sở V1. Do đó 125 LOC được tạo thành từ 100 LOC mới và 25 LOC
sửa đổi. Thông báo, tuy nhiên, các LỘC 100 chỉ được hiển thị trong cột gia tăng
trên bên trái của bảng 3.2, nhưng 25 LOC được thể hiện trong cả hai thêm vào và trừ
các cột. Lý do là một LỘC sửa đổi phải được tính là một bổ sung một dòng
và một xóa một dòng. Điều này là do dòng mà đã được tính trong cơ sở. Nếu
bạn không trừ đi 25, bạn sẽ đôi đếm nó. Phiên bản 1 (hoặc phiên bản 2 cơ sở)
đã được thể hiện để chứa 450 LOC, chỉ là phản chỉ định.
đang được dịch, vui lòng đợi..
Các ngôn ngữ khác
Hỗ trợ công cụ dịch thuật: Albania, Amharic, Anh, Armenia, Azerbaijan, Ba Lan, Ba Tư, Bantu, Basque, Belarus, Bengal, Bosnia, Bulgaria, Bồ Đào Nha, Catalan, Cebuano, Chichewa, Corsi, Creole (Haiti), Croatia, Do Thái, Estonia, Filipino, Frisia, Gael Scotland, Galicia, George, Gujarat, Hausa, Hawaii, Hindi, Hmong, Hungary, Hy Lạp, Hà Lan, Hà Lan (Nam Phi), Hàn, Iceland, Igbo, Ireland, Java, Kannada, Kazakh, Khmer, Kinyarwanda, Klingon, Kurd, Kyrgyz, Latinh, Latvia, Litva, Luxembourg, Lào, Macedonia, Malagasy, Malayalam, Malta, Maori, Marathi, Myanmar, Mã Lai, Mông Cổ, Na Uy, Nepal, Nga, Nhật, Odia (Oriya), Pashto, Pháp, Phát hiện ngôn ngữ, Phần Lan, Punjab, Quốc tế ngữ, Rumani, Samoa, Serbia, Sesotho, Shona, Sindhi, Sinhala, Slovak, Slovenia, Somali, Sunda, Swahili, Séc, Tajik, Tamil, Tatar, Telugu, Thái, Thổ Nhĩ Kỳ, Thụy Điển, Tiếng Indonesia, Tiếng Ý, Trung, Trung (Phồn thể), Turkmen, Tây Ban Nha, Ukraina, Urdu, Uyghur, Uzbek, Việt, Xứ Wales, Yiddish, Yoruba, Zulu, Đan Mạch, Đức, Ả Rập, dịch ngôn ngữ.
- regardless
- My lower secondary school is called by N
- ngày nay điện thoại được sử dụng rất phổ
- A: Xin chào, tại sao trông bạn buồn thế?
- the mortgage
- Giúp bạn năng động trong môi trường xã h
- Một tiếng sau
- ghastly
- build a bridge over the canal villagers
- A: Xin chào, tại sao trông bạn buồn thế?
- giúp làm quen và kết bạn trên khắp thế g
- Tôi thấy ở trung tâm tiếng anh thành phố
- English Speaking Competition
- a pain in your head
- you tell me frankly
- If i feel too excited to sleep , I would
- niềm vui
- the measures must be precise, specific,
- faraway
- Tôi ước tôi xinh đẹp,cao ,thông minh , h
- Có một chế độ ăn uống hợp lý
- đôi giày cao gót
- ví dụ như
- A: Xin chào, tại sao trông bạn buồn thế?
