The initial part of the name is the

The initial part of the name is the project name, PCL-TOOLS. In this project,
there are a number of separate tools being developed, so the tool name (EDIT) is
used as the next part of the name. Each tool includes differently named modules
whose name makes up the next component of the item identifier (FORMS, HELP).
This decomposition process continues until the base-level formal documents are ref-
erenced (Figure 29.2). The leaves of the documentation hierarchy are the formal con-
figuration items. Figure 29.2 shows that three formal items are required for each code
component: an object description (OBJECTS), the source code of the component
(CODE) and a set of tests for that component (TESTS). Items such as help frames
are also managed and have different names (FR-1, in the preceding example).
Hierarchical naming schemes are simple and easily understood, and sometimes
they can map to the directory structures used to store project files. However, they
reflect the structure of the project where the software was developed. The config-
uration item names associate components with a particular project and so may reduce
the opportunities for reuse. It can be very hard to find related components (e.g., all
components developed by the same programmer) where the relationship is not reflected
in the item-naming scheme.
29.1.2 ' The configuration database
The configuration database is used to record all relevant information about system
configurations and configuration items. You use the CM database to help assess the
impact of system changes and to generate reports for management about the CM
process. As part of the CM planning process, you should define the CM database schema, the forms to collect information to be recorded in the database and proce-
dures for recording and retrieving project information.
A configuration database does not just include information about configuration items.
It may also record information about users of components, system customers, execu-
tion platforms, proposed changes and so forth. It should be able to provide answers
to a variety of queries about system configurations. Typical queries might be:
1. Which customers have taken delivery of a particular version of the system?
2. What hardware and operating system configuration is required to run a given
system version?
3. How many versions of a system have been created and what were their cre-
ation dates?
4. What versions of a system might be affected if a particular component is changed?
5. How many change requests are outstanding on a particular version?
6. How many reported faults exist in a particular version?
Ideally, the configuration database should be integrated with the version man-
agement system that is used to store and manage the formal project documents. This
approach, supported by some integrated CASE tools, makes it possible to link changes
directly with the documents and components affected by the change. Links between
documents (such as design documents) and program code may be maintained so
that you can find everything that you have to modify when a change is proposed.
However, integrated CASE tools for configuration management are expensive.
Many companies do not use them but maintain their configuration database sepa-
rate from their version control systems. They store configuration items as files in
a directory structure or in a version management system such as CVS (Berliner,
1990), discussed later in this chapter.
The configuration database stores information about the configuration items and
references their names in the version management system or filestore. While this
is a relatively cheap and flexible approach, the problem with it is that configura-
tion items may be changed without going through the configuration database.
Therefore, you can't be completely sure that the configuration database is an up-
to-date description of the state of the system.
I
29.2 Change management
Change is a fact of life for large software systems. As I have discussed in earlier
chapters, organisational needs and requirements change during the lifetime of a system

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

Phần đầu của tên là tên của dự án, công CỤ PCL. Trong dự án này, có một số công cụ riêng biệt đang được phát triển, do đó, tên công cụ (chỉnh SỬA) được sử dụng như là một phần tiếp theo của tên. Mỗi công cụ bao gồm các mô-đun được đặt tên theo một cách khác nhau tên mà làm thành phần tiếp theo của các định danh mục (hình THỨC giúp ĐỠ). Quá trình phân hủy này tiếp tục cho đến khi tài liệu chính thức của cấp độ cơ bản ref- erenced (hình 29.2). Các lá của hệ thống phân cấp tài liệu hướng dẫn là con chính thức- Các mặt hàng figuration. Hình 29.2 cho thấy ba mục chính thức được yêu cầu cho mỗi mã thành phần: một mô tả đối tượng (đối TƯỢNG), mã nguồn của các thành phần (Mã SỐ) và một bộ các xét nghiệm cho các thành phần đó (thử NGHIỆM). Các hạng mục như giúp khung cũng được quản lý và có tên gọi khác nhau (FR-1, trong ví dụ trước). Phân cấp các chương trình đặt tên là đơn giản và dễ hiểu, và đôi khi họ có thể bản đồ với các cấu trúc thư mục được sử dụng để lưu trữ các tập tin dự án. Tuy nhiên, họ phản ánh cấu trúc của các dự án mà các phần mềm được phát triển. Config- uration mục tên liên kết các thành phần với một dự án cụ thể và do đó có thể làm giảm cơ hội để tái sử dụng. Nó có thể rất khó để tìm thấy các thành phần liên quan (ví dụ: tất cả Các thành phần được phát triển bởi các lập trình viên cùng) mà không phản ánh các mối quan hệ trong sơ đồ đặt tên mục. 29.1.2 ' cơ sở dữ liệu cấu hình Cơ sở dữ liệu cấu hình được sử dụng để ghi lại tất cả thông tin liên quan về hệ thống cấu hình và cấu hình các mặt hàng. Bạn sử dụng cơ sở dữ liệu CM để giúp đánh giá các tác động của thay đổi hệ thống và tạo các báo cáo cho quản lý về CM quá trình. Là một phần của quá trình lập kế hoạch CM, bạn nên xác định các lược đồ cơ sở dữ liệu CM, các hình thức thu thập thông tin được ghi lại trong cơ sở dữ liệu và proce- dures để ghi lại và truy xuất thông tin dự án. Cơ sở dữ liệu cấu hình không chỉ bao gồm các thông tin về các mục cấu hình. Nó cũng có thể ghi lại các thông tin về người dùng của các thành phần hệ thống khách hàng, execu- tion nền tảng, đã đề xuất thay đổi và vv. Nó có thể cung cấp cho câu trả lời với một loạt các truy vấn về cấu hình hệ thống. Điển hình truy vấn có thể là: 1. mà khách hàng đã cung cấp một phiên bản đặc biệt của hệ thống? 2. cấu hình phần cứng và hệ điều hành là cần thiết để chạy một nhất định Phiên bản hệ thống? 3. làm thế nào nhiều phiên bản của một hệ thống đã được tạo ra và những gì đã là họ cre- ẻ ngày? 4. những gì phiên bản của một hệ thống có thể bị ảnh hưởng nếu một thành phần đặc biệt là thay đổi? 5. có bao nhiêu thay đổi yêu cầu là xuất sắc trên một phiên bản đặc biệt? 6. làm thế nào nhiều báo cáo lỗi tồn tại trong một phiên bản đặc biệt? Lý tưởng nhất, tích hợp cơ sở dữ liệu cấu hình với phiên bản người đàn ông- Hệ thống agement được sử dụng để lưu trữ và quản lý các tài liệu chính thức dự án. Điều này cách tiếp cận, được hỗ trợ bởi một số công cụ tích hợp trường HỢP, làm cho nó có thể liên kết thay đổi trực tiếp với các tài liệu và các thành phần bị ảnh hưởng bởi sự thay đổi. Liên kết giữa các tài liệu (như các tài liệu thiết kế) và mã số chương trình có thể được duy trì như vậy bạn có thể tìm thấy tất cả mọi thứ mà bạn có thể thay đổi khi thay đổi được đề xuất. Tuy nhiên, trường HỢP công cụ để quản lý cấu hình là tốn kém. Nhiều công ty không sử dụng, nhưng duy trì của họ cấu hình cơ sở dữ liệu sepa- mức từ hệ thống điều khiển phiên bản của họ. Họ lưu trữ các mục cấu hình với các tệp trong một cấu trúc thư mục hoặc trong một hệ thống quản lý phiên bản như CVS (Berliner, năm 1990), được thảo luận sau đó trong chương này. Cơ sở dữ liệu cấu hình lưu trữ thông tin về các mục cấu hình và tài liệu tham khảo tên của họ trong hệ thống quản lý phiên bản hoặc khoải. Trong khi điều này là một cách tiếp cận tương đối rẻ và linh hoạt, các vấn đề với nó là configura đó - tion mục có thể thay đổi mà không qua cơ sở dữ liệu cấu hình. Vì vậy, bạn không thể hoàn toàn chắc chắn rằng cơ sở dữ liệu cấu hình một up- đến ngày các mô tả của nhà nước của hệ thống. Tôi 29.2 quản lý thay đổi Thay đổi là một thực tế của cuộc sống cho các hệ thống phần mềm lớn. Như tôi đã thảo luận trong trước đó chương, nhu cầu tổ chức và yêu cầu thay đổi trong suốt cuộc đời của một hệ thống

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

Phần đầu tiên của tên này là tên dự án, PCL-TOOLS. Trong dự án này,
có một số công cụ riêng biệt đang được phát triển, vì vậy tên công cụ (EDIT) được
sử dụng như là một phần tiếp theo của tên. Mỗi công cụ bao gồm chỉ khác tên module
có tên tạo nên các thành phần tiếp theo của bộ nhận diện mục (HÌNH THỨC, HELP).
Quá trình phân hủy này tiếp tục cho đến khi các tài liệu chính thức cơ sở cấp là ref-
erenced (Hình 29.2). Các lá của hệ thống phân cấp tài liệu hướng dẫn là những niệm chính thức
mục biểu hiệu. Hình 29.2 cho thấy ba mục chính thức được yêu cầu cho mỗi mã
thành phần: một mô tả đối tượng (ĐỐI TƯỢNG), mã nguồn của các thành phần
(CODE) và một loạt các thử nghiệm cho component (Độ). Các hạng mục như khung giúp đỡ
cũng được quản lý và có tên gọi khác nhau (FR-1, trong ví dụ trước).
Đề án đặt tên thứ bậc rất đơn giản và dễ hiểu, và đôi khi
họ có thể ánh xạ vào các cấu trúc thư mục được sử dụng để lưu trữ các file dự án. Tuy nhiên, họ
phản ánh cấu trúc của các dự án mà các phần mềm đã được phát triển. Các Configure
tên mục uration thành phần liên kết với một dự án cụ thể và do đó có thể làm giảm
các cơ hội để tái sử dụng. Nó có thể rất khó để tìm thấy các thành phần liên quan (ví dụ, tất cả
các thành phần được phát triển bởi các lập trình viên cùng), nơi các mối quan hệ không phản ánh
trong chương trình mục đặt tên.
29.1.2 'Cơ sở dữ liệu cấu hình
cơ sở dữ liệu cấu hình được sử dụng để ghi lại tất cả các thông tin có liên quan về hệ thống
cấu hình và các mục cấu hình. Bạn sử dụng các cơ sở dữ liệu CM để giúp đánh giá các
tác động của thay đổi hệ thống và tạo các báo cáo cho quản lý về CM
quá trình. Là một phần của quá trình lập kế hoạch CM, bạn nên xác định các lược đồ cơ sở dữ liệu CM, các hình thức thu thập thông tin để ghi vào cơ sở dữ liệu và proce-
các thủ để ghi âm và lấy thông tin dự án.
Một cơ sở dữ liệu cấu hình không chỉ bao gồm thông tin về các mục cấu hình.
nó cũng có thể ghi lại thông tin về người sử dụng của các thành phần, khách hàng hệ thống, execu-
nền tảng sự, đề xuất thay đổi và vv. Nó sẽ có thể cung cấp câu trả lời
cho một loạt các truy vấn về cấu hình hệ thống. Truy vấn điển hình có thể là:
1. Những khách hàng đã giao hàng của một phiên bản đặc biệt của hệ thống?
2. Phần cứng và cấu hình hệ điều hành gì là cần thiết để chạy một cho
phiên bản hệ?
3. Làm thế nào nhiều phiên bản của một hệ thống đã được tạo ra và những gì là cre- của họ
ngày ation?
4. Những phiên bản của một hệ thống có thể bị ảnh hưởng nếu một thành phần đặc biệt được thay đổi?
5. Làm thế nào nhiều yêu cầu thay đổi rất xuất sắc trên một phiên bản đặc biệt?
6. Làm thế nào nhiều báo cáo lỗi tồn tại trong một phiên bản đặc biệt?
Lý tưởng nhất, cơ sở dữ liệu cấu hình nên được tích hợp với các phiên bản lý
hệ thống quản được sử dụng để lưu trữ và quản lý các tài liệu dự án chính thức. Điều này
tiếp cận, hỗ trợ bởi một số công cụ CASE tích hợp, làm cho nó có thể liên kết thay đổi
trực tiếp với các tài liệu và các thành phần bị ảnh hưởng bởi sự thay đổi. Liên kết giữa
các tài liệu (chẳng hạn như tài liệu thiết kế) và mã chương trình có thể được duy trì như vậy
mà bạn có thể tìm thấy tất cả mọi thứ mà bạn phải thay đổi khi thay đổi được đề xuất.
Tuy nhiên, tích hợp các công cụ CASE cho quản lý cấu hình là tốn kém.
Nhiều công ty không sử dụng chúng nhưng duy trì cơ sở dữ liệu cấu hình của họ sepa-
tỷ lệ từ hệ thống kiểm soát phiên bản của họ. Họ lưu các mục cấu hình như các tập tin trong
một cấu trúc thư mục hoặc trong một hệ thống quản lý phiên bản như CVS (Berliner,
1990), thảo luận sau trong chương này.
Các thông tin cấu hình lưu trữ cơ sở dữ liệu về các mục cấu hình và
tài liệu tham khảo tên của họ trong hệ thống quản lý phiên bản hay filestore. Trong khi điều này
là một cách tiếp cận tương đối rẻ và linh hoạt, các vấn đề với nó là configura-
mục sự có thể được thay đổi mà không thông qua cơ sở dữ liệu cấu hình.
Vì vậy, bạn có thể không hoàn toàn chắc chắn rằng cơ sở dữ liệu cấu hình là một up-
to-date Mô tả các trạng thái của hệ thống.
tôi
29,2 quản lý thay đổi
Thay đổi là một thực tế của cuộc sống cho các hệ thống phần mềm lớn. Như tôi đã thảo luận ở đầu
chương, nhu cầu tổ chức và yêu cầu thay đổi trong suốt cuộc đời của một hệ thống