Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.33 MB, 184 trang )
<span class="text_page_counter">Trang 1</span><div class="page_container" data-page="1">
TP. HCM, 2004
</div><span class="text_page_counter">Trang 4</span><div class="page_container" data-page="4">Luận văn của chúng em sẽ rất khó hồn thành nếu khơng có sự truyền đạt kiến thức quí báu và sự hướng dẫn tận tình của Thầy Trần Đan Thư và thầy Nguyễn Trọng Tài. Chúng em xin chân thành cám ơn sự chỉ bảo của các thầy.
Chúng con xin gửi tất cả lịng biết ơn, sự kính trọng đến ơng bà, cha mẹ, cùng tồn thể gia đình, những người đã nuôi dạy, đã cho chúng con niềm tin và nghị lực để vượt qua mọi khó khăn.
Chúng em xin trân trọng cám ơn quý Thầy cô trong Khoa Công nghệ thông tin trường Đại học Khoa học Tự nhiên Tp.Hồ Chí Minh đã tận tình giảng dạy, truyền đạt những kiến thức quý báu và tạo điều kiện cho chúng em được thực hiện luận văn này.
Xin chân thành cám ơn sự giúp đỡ, động viên và chỉ bảo rất nhiệt tình của các anh chị đi trước và tất cả bạn bè. Các anh chị, các bạn ln có mặt trong những thời điểm khó khăn nhất, tiếp thêm động lực và ý chí, giúp chúng tơi hồn thành được luận văn.
Mặc dù đã cố gắng nỗ lực hết sức mình, song chắc chắn luận văn khơng khỏi cịn nhiều thiếu sót. Chúng em rất mong nhận được sự thông cảm và chỉ bảo tận tình của q Thầy cơ và các bạn.
Nhóm sinh viên thực hiện
Hồ Nguyễn Ngọc Phương – Triệu Ngọc Toàn
</div><span class="text_page_counter">Trang 5</span><div class="page_container" data-page="5">mũi nhọn được nhà nước ta ưu tiên phát triển đặc biệt là lĩnh vực công nghệ phần mềm. Tuy nhiên, lĩnh vực công nghệ phần mềm của nước ta vẫn còn khá non trẻ so với nền công nghệ phần mềm của thế giới. Nên trong giai đọan hiện nay, các công ty phần mềm thường gặp rất nhiều khó khăn liên quan đến qui trình phát triển phần mềm.
Quản lý cấu hình phần mềm vốn là một vấn đề rất được quan tâm trong qui trình sản xuất phần mềm. Hiện nay, qui trình quản lý cấu hình phần mềm tại phòng phát triển phần mềm trực thuộc trung tâm tin học trường Đại Học Khoa Học Tự Nhiên Tp. Hồ Chí Minh vẫn chưa được hoàn chỉnh. Do đó, việc hoàn thiện một hệ thống quản lý cấu hình ở đây là cần thiết cho quá trình sản xuất phần mềm hiện tại được thuận tiện hơn và chuẩn bị cho việc thực các đề án phần mềm lớn sau này đạt hiệu qủa cao.
Từ nhu cầu nói trên, chúng em đã tiến hành thực hiện đề tài “Quản lý cấu hình phần mềm tại phòng phát triển phần mềm Quang Trung – Trung tâm tin học”. Nhằm mục đích cùng với phòng phát triển phần mềm thiết lập một hệ thống quản lý cấu hình tốt có thể áp dụng vào quá trình sản xuất phần mềm của trung tâm.
Nội dung của luận văn được chia làm 7 chương
<b>Chương 1: Mở đầu </b>
<b>Chương 2: Tổng quan về quản lý cấu hình phần mềm </b>
<b>Chương 3: Quản lý cấu hình phần mềm trong CMM & CMMI </b>
<b>Chương 4: Các vấn đề thường gặp trong quản lý cấu hình phần mềm và giải </b>
pháp
<b>Chương 5: Các công cụ hỗ trợ quản lý cấu hình phần mềm Chương 6: Ứng dụng Software Version Management Chương 7: Tổng kết </b>
</div><span class="text_page_counter">Trang 6</span><div class="page_container" data-page="6">1.1 Quản lý cấu hình phần mềm trên thế giới và ở Việt Nam ...1
1.2 Các công cụ hỗ trợ quản lý cấu hình hiện tại...2
1.3 Mục tiêu đề tài...2
Chương 2 Tổng quan về quản lý cấu hình phần mềm ...4
2.1 Khái niệm...4
2.2 Nguồn gốc hình thành của quản lý cấu hình...5
2.3 Phạm vi và nhiệm vụ của quản lý cấu hình ...6
2.3.1 Mức độ mong muốn và việc phân tích chi phí và lợi nhuận ...6
2.3.2 Ví dụ...8
2.3.3 Cân nhắc lợi hại ...12
2.3.4 Những bẫy kết hợp với phạm vi ...16
2.3.5 Cách xứ lý các thứ khác ở bên ngoài ...16
2.4 Các vai trò trong quản lý cấu hình phần mềm ...17
2.4.1 Con người và quản lý cấu hình ...17
2.4.2 Các vai trò trong quản lý cấu hình ...18
2.4.3 Các vai trò trong tổ chức...23
2.4.4 Các vai trò liên quan đến đề án...28
2.4.5 Các vai trò bên ngoài ...35
2.5 Dữ liệu cho quản lý cấu hình ...36
2.5.1 Cái gì được đưa vào quản lý cấu hình ...36
2.5.2 Những điều cần biết về một thành phần cấu hình...44
2.6 Hệ thống quản lý cấu hình phần mềm ...53
2.6.1 Khái niệm:...53
2.6.2 Mục tiêu ...54
2.6.3 Lợi ích ...54
2.6.4 Các tiến trình con trong quản lý cấu hình phần mềm ...54
Chương 3 Quản lý cấu hình phần mềm trong CMM & CMMI...56
</div><span class="text_page_counter">Trang 7</span><div class="page_container" data-page="7">3.2.1 Mức độ trưởng thành của CMM Version 1.1 ...56
3.2.2 Quản lý cấu hình phần mềm trong CMM version 1.1 ...57
3.3 Quản lý cấu hình trong CMMI...59
3.3.1 Các mức trưởng thành của CMMI ...59
3.3.2 Quản lý cấu hình trong CMMI ...60
Chương 4 Vấn đề định danh, quản lý phiên bản và các giải pháp...76
4.1 Đặt tên các đối tượng cấu hình ...76
4.1.1 Đặt tên phân cấp dựa theo cấu trúc cây. ...76
4.1.2 Đặt tên phân cấp dựa theo phương pháp tiền tố và hậu tố...77
4.1.3 Nhận xét chung ...79
4.2 Xác định và định danh phiên bản...79
4.2.1 Sơ đồ tuyến tính ...80
4.2.2 Sơ đồ định danh theo mạng. ...80
4.2.3 Sơ đồ định danh theo tên...81
Chương 5 Các công cụ hỗ trợ quản lý cấu hình...82
5.4.2 Cấu trúc của CVSNT ...84
Chương 6 Ứng dụng minh họa “System Version Management” ...86
6.1 Phân tích hiện trạng phát triển phần mềm tại T3H ...86
6.2 Đặc tả yêu cầu của hệ thống mới ...95
6.3 Mô hình UseCase ...99
</div><span class="text_page_counter">Trang 8</span><div class="page_container" data-page="8">6.4.5 Đặc tả UseCase : Cập nhật cây phân hệ, chức năng ...106
6.4.6 Đặc tả UseCase : Tạo release...108
6.4.7 Đặc tả UseCase : Gán nhãn cho các thực thể ...109
6.4.8 Đặc tả UseCase : Phân quyền ...110
6.4.9 Đặc tả UseCase : Thiết lập ảnh hưởng giữa các versionfile ...112
6.4.10 Đặc tả UseCase : Xem lịch sử phiên bản của thực thể...113
6.4.11 Đặc tả UseCase : Thực hiện check in...114
6.4.12 Đặc tả UseCase : Thực hiện check out...115
6.4.13 Đặc tả UseCase : Get...116
6.5 Thiết kế ...118
6.5.1 Kiến trúc hệ thống...118
6.5.2 Giao diện ...118
6.5.3 Mô hình lớp đối tượng ...123
6.5.4 Mô hình dữ liệu...144
6.6 Mô hình thiết kế ...157
6.6.1 Đăng nhập ...157
6.6.2 Thêm kho chứa...158
6.6.3 Thêm đề án...158
6.6.4 Xem Cấu trúc của project ...159
6.6.5 Xem kiến trúc của đề án...159
</div><span class="text_page_counter">Trang 9</span><div class="page_container" data-page="9">7.1 Tự đánh giá ...1657.2 Hướng phát triển ...165
</div><span class="text_page_counter">Trang 10</span><div class="page_container" data-page="10">Hình 2-1 Cây cấu hình phần mềm ...5
Hình 2-2 Tổng chi phí của quản lý cấu hình...8
Hình 2-3 Nhiều ban quản lý cấu hình ...20
Hình 2-4 Khách hàng, người ký hợp đồng, các hợp đồng phụ ...35
Hình 2-5 Sơ đồ phân cấp các thực thể cấu hình...36
Hình 2-6 Đặc tả yêu cầu của một delivery...41
Hình 2-7 Mối quan hệ về phần cứng của delivery...42
Hình 2-8 Tổng quan về siêu dữ liệu...45
Hình 2-9 Siêu dữ liệu nhận biết sự duy nhất...46
Hình 2-10 Siêu dữ liệu cho việc phân trách nhiệm...50
Hình 2-11 Siêu dữ liệu chỉ mối quan hệ đến các thực thể cấu hình khác ...51
Hình 2-12 Ví dụ của việc theo vết ...52
Hình 2-13 Sơ đồ các tiến trình con trong quản lý cấu hình ...55
Hình 3-1 các mức trưởng thành của CMMI...59
Hình 4-1 Cây phân cấp đặt tên...77
Hình 4-2 Sơ đờ định danh theo mạng ...81
Hình 6-1 Qui trình phát triển phần mềm của T3H...87
Hình 6-2 Sơ đồ phân cấp vai trò của nhân viên trong hệ thớng...92
Hình 6-3 Cây phân cấp theo cấu trúc...93
Hình 6-4 Cây phân cấp theo phân hệ / kiến trúc...93
Hình 6-5 Sơ đồ hoạt động của hệ thống hiện tại...95
Hình 6-6 Kiến trúc về phần cứng hệ thống ...118
Hình 6-7 Màn hình chính ...119
Hình 6-8 Màn hình thiết lập mối quan hệ giữa các tập tin...120
Hình 6-9 Màn hình thiết lập kiến trúc từ cấu trúc...121
Hình 6-10 Màn hình xem thông tin của project, kho chứa, thư mục ...121
Hình 6-11 Màn hình xem thông tin của tập tin và phiên bản của nó...122
</div><span class="text_page_counter">Trang 11</span><div class="page_container" data-page="11">Hình 6-12 Màn hình xem lịch sử của tập tin, thư mục, project ...122Hình 6-13 Mô hình lớp đới tượng ...123Hình 6-14 Mơ hình dữ liệu của hệ thống ...144
</div><span class="text_page_counter">Trang 12</span><div class="page_container" data-page="12">Bảng 2-1 Mô tả những hoạt động với mức độ hình thức thấp ...9
Bảng 2-2 Mơ tả hoạt động với mức độ hình thức cao ...11
Bảng 2-3 Ví dụ về tiết kiệm khi sử dụng hệ thống Quản lý cấu hình...15
Bảng 2-4 Thành phần tên và chức năng của nó ...47
Bảng 3-1 Mức độ trưởng thành của CMM ...57
Bảng 3-2 Các mức trưởng thành và các vùng tiến trình của CMMI...60
Bảng 3-3 Danh sách các thực tiễn cho cho SG 1 ...64
Bảng 3-4 Danh sách các thực tiễn cho cho SG 2 ...64
Bảng 3-5 Danh sách các thực tiễn cho cho SG 3 ...64
Bảng 4-1 Diễn giải từ viết tắt cho qui tắc đặt tên ...78
</div><span class="text_page_counter">Trang 13</span><div class="page_container" data-page="13"><b>Thuật ngữ dùng trong CMMI </b>
<b>STT Thuật ngữ Diễn giải </b>
<b>1. </b>
<b>Process Areas (PA) – Vùng tiến trình </b>
<b>Vùng tiến trình (Process Areas PA): Mỗi PA là một </b>
nhóm các hoạt động thực tiễn có liên hệ với nhau, nhằm để đạt được một số mục tiêu quan trọng của việc cải tiến quy trình phần mềm
<b>(SG) – Mục tiêu chuyên biệt </b>
<b>Mục tiêu chuyên biệt (Specific Goals - SG): Các </b>
mục tiêu chuyên biệt áp dụng cho một vùng tiến trình và nhắm vào các đặc trưng riêng biệt mơ tả nhữg việc gì cầm triển khai để thoả mãn vùng tiến trình đó. Những mục tiêu này cũng được dùng trong việc đánh giá để xác định xem một tổ chức có triển khai hồn tất một vùng tiến trình nào đó hay không
<b>3. </b>
<b>Specific </b>
<b>Practices (SP) – Quy tắc thực tiễn chuyên biệt </b>
<b>Quy tắc thực tiễn chuyên biệt (Specific Practices – SP): Một quy tắc thực tiễn chun biệt là một hoạt </b>
động đóng vai trị quan trọng để góp phần đạt được mục tiêu chuyên biệt tương ứng
<b>4. </b>
<b>Generic Goals (GG) – Mục tiêu tổng quát </b>
<b>Mục tiêu tổng quát (Generic Goals - GG): Các mục </b>
tiêu tổng quát được gọi là “tổng quát” bởi vì cùng một khẳng định được xuất hiện trong nhiều vùng tiến trình khác nhau.
</div><span class="text_page_counter">Trang 14</span><div class="page_container" data-page="14"><b>Thuật ngữ về Quản lý cấu hình </b>
<b>STT Thuật ngữ Diễn giải </b>
<b>tra </b>
<b>Kiểm tra (Audit): kiểm tra một thực thể cấu hình </b>
được phát hành sử dụng có đáp ứng đầy đủ các đặc tả yêu cầu. (Áp dụng trong hoạt động quản lý chất lượng)
<b>2. </b>
<b>Baseline – Cấu hình cơ sở </b>
<b>Cấu hình cơ sở (Baseline): Là một tập hợp các yêu </b>
cầu, thiết kế, mã nguồn, các tập tin định nghĩa tham số biên dịch hay nối kết, tài liệu người dùng,.. được nhóm lại và gán cho một tên duy nhất
<b>3. </b>
trữ vào trong một thư viện được kiểm soát để tạo sản
<b>phẩm. </b>
<b>nơi lưu trữ sau khi check out. </b>
<b>5. </b>
<b>Configuration Control Board (CCB) – Ban quản lý cấu hình. </b>
<b>Configuration Change Board – Ban kiểm sốt thay đổi cấu hình </b>
<b>Ban quản lý cấu hình (Configuration Control Board), Ban kiểm sốt thay đổi cấu hình </b>
<b>(Configuration Change Board) : Một nhóm người </b>
chịu trách nhiệm sở hữu, chấp nhận hoặc từ chối, đưa ra đề nghị thay đổi đối với thực thể cấu hình và chịu trách nhiệm về việc thực hiện, phê duyệt các
<b>thay đổi </b>
<b>item – Thực </b>
<b>Thực thể cấu hình (Configuration item): Một sản </b>
phẩm cơng việc trung gian, các thành tố (component)
</div><span class="text_page_counter">Trang 15</span><div class="page_container" data-page="15"><b>Hệ thống quản lý cấu hình (Configuration management system): Tất cả các định nghĩa quy </b>
trình, các biểu mẫu, các cơng cụ thu thập để hỗ trợ quản lý cấu hình trong một mơi trường cụ thể
<b>Siêu dữ liệu (Metadata): Thơng tin về các thực thể </b>
cấu hình. Ví dụ: một tài liệu đặt dưới quản lý cấu hình là một thực thể cấu hình, trong khi tên và số của tài liệu là siêu dữ liệu về thực thể tài liệu đó.
<b>11. </b>
<b>Procedure – Quy trình </b>
<b>Quy trình (Procedure): Số lượng các hoạt động theo thứ tự với các thông tin đầu vào và đầu ra cố </b>
<b>định </b>
<b>12. </b>
<b>Process – Tiến trình </b>
<b>Tiến trình (Process): Mơ tả cách sử dụng các thông </b>
tin đầu vào để tạo ra kết qủa đầu ra như mong muốn. Số lượng công việc trong quy trình được mơ tả trong các tài liệu mơ tả về tiến trình
<b>13. </b>
<b>Process </b>
<b>description – Mơ tả tiến trình </b>
<b>Mơ tả tiến trình (Process description): Mơ tả các </b>
kỹ thuật, phương pháp, các quy ước, các quy trình
<b>liên hệ với một hoạt động nào đó. </b>
<b>14. </b>
<b>Product – Sản phẩm </b>
<b>Sản phẩm (Product): có thể là sản phẩm sử dụng </b>
nội bộ hay là sản phẩm được phát hành ra bên ngoài
<b>cho khách hàng </b>
</div><span class="text_page_counter">Trang 16</span><div class="page_container" data-page="16"><b>Phiên bản (Version): Là một thể hiện của phần </b>
mềm mà có sự thay đổi so với các thể hiện khác của phần mềm đó. Sự thay đổi có thể bao gồm: các chức năng mới, cải tiến hiệu năng (tốc độ, không gian lưu trữ,..), sửa đổi các lỗi của phiên bản cũ. Một số phiên bản có thể tương đương hồn tồn về mặt chức năng nhưng được thiết kế để dùng cho các cấu hình phần mềm hay phần cứng khác nhau.
<b>17. </b>
<b>Support </b>
<b>process – Quy trình hỗ trợ </b>
<b>Quy trình hỗ trợ (Support process): Quy trình </b>
dùng trong tất cả các quy trình khác tại các thời điểm khác nhau trong vòng đời của đế án phần mềm. Những quy trình hỗ trợ bản thân khơng có ý nghĩa gì
<b>cả. Nó chỉ có ý nghĩa khi được dùng với một quy </b>
trình khác.
Ví dụ: Việc định danh là một quy trình hỗ trợ; việc định danh chỉ có ý nghĩa nếu có một quy trình khác tạo ra sản phẩm và đặt tên sản phẩm.
</div><span class="text_page_counter">Trang 17</span><div class="page_container" data-page="17">Quản lý cấu hình phần mềm - SCM - là một tiến trình trong quá trình phát triển phần mềm xuất hiện cách đây hơn 20 năm (vào khoảng năm 1980). Tiến trình này giúp cho các nhà phát triển phần mềm kiểm sóat được những thay đổi và kiến trúc của hệ thống phần mềm đang phát triển.
Vào giai đọan mới hình thành tiến trình quản lý phần mềm chủ yếu được thực hiện đơn lẻ bởi những công ty phần mềm. Tuy nhiên, hầu hết các công ty đều nhận thấy công việc quản lý sự thay đổi của phần mềm là vô cùng phức tạp và tốn kém. Chính vì vậy, đã xuất hiện các công ty chuyên cung cấp các giải pháp chọn gói về quản lý cấu hình phần mềm và các công cụ để hỗ trợ cho tiến trình này. Ví dụ: Rational, Seapine, ...
Hiện nay, Tiến trình quản lý cấu hình phần mềm đã được viện nghiên cứu công nghệ phần mềm SEI tổ chức và sắp xếp lại các họat động của tiến trình này trở thành một phần của CMM và CMMI . Đồng thời cung cấp nhiều tài liệu hướng dẫn việc thực hiện và áp dụng tiến trình này vào quá trình phát triển phần mềm chung. Từ đó, các công ty phần mềm cảm thấy việc quản lý cấu hình phần mềm trở nên rõ ràng hơn và các công ty hay tổ chức cá nhân chuyên về giải pháp quản lý cấu hình phần mềm đã phát triển ra các công cụ riêng lẽ hỗ trợ cho từng bước của tiến trình CM hay tồn bợ.
Trên thế giới, các công ty phần mềm lớn như Microsoft hoặc IBM, Oracle ... đã tiến hành xây dựng tiến trình quản lý cấu hình phần mềm riêng của mình nhờ vào kinh nghiệm phát triển của chính họ và sự tư vấn của các chuyên gia từ các viện nghiên cứu phần mềm như S.E.I hay S.E.L và phát triển các công cụ riêng phục vụ cho tiến trình này. Với các công ty nhỏ ít vốn và kinh nghiệm thì mua các công cụ
</div><span class="text_page_counter">Trang 18</span><div class="page_container" data-page="18">Hiện tại, các công cụ hỗ trợ cho việc quản lý quy trình sản xuất phần mềm xuất hiện ngày càng nhiều. Một số công cụ đã xuất hiện từ lâu và được hoàn thiện dần nên có chất lượng rất tốt. Chẳng hạn như các công cụ quản lý phần mềm thương mại Clear Case của hãng Rational Rose hỗ trợ cho qui trình phát triển phần mềm RUP, Surround SCM và Test Track Pro Intergration của hãng Seapine ... thường có chi phí cao và được áp dụng cho các đề án phần mềm lớn hoặc các công ty lớn giàu kinh nghiệm, đặc biệt là các phần mềm này được xây dựng và áp dụng theo một quy trình sản xuất phần mềm chuyên biệt (ví dụ như clear Case áp dụng theo quy trình RUP).
Mục tiêu của đề được đặt ra liên quan đến qui trình quản lý cấu hình tại phòng phát triển phần mềm Quang Trung – Trung tâm tin học.
Các công việc chính mà đề tài cần phải giải quyết:
• Tìm hiểu về các phương pháp quản lý cấu hình và các kỹ thuật cụ thể được dùng trong quản lý cấu hình
</div><span class="text_page_counter">Trang 19</span><div class="page_container" data-page="19">• Tìm hiểu mợt sớ cơng cụ hỡ trợ cho việc quản lý cấu hình.
• Tìm hiểu hiện trạng và qui trình sản xuất phần mềm của phòng phát triển phần mềm trung tâm tin học.
• Xác định các yêu cầu cần phải thực hiện và các thông tin cần phải quản lý để hỗ trợ cho cho qui trình phát triển mà trung tâm đang mong muốn xây dựng trên qui trình hiện tại.
• Đưa ra các giải pháp về phần mềm để hỗ trợ qui trình đó và thay thế một số phần mềm đang đang sử dụng bằng những phần mềm bằng những phần mềm khác tương đương nhưng có những chức năng hỗ trợ khác hoặc xây dựng một phần mềm mới phối hợp với các phần mềm hiện có hay thêm mới.
• Triển khai việc áp dụng hệ thớng quản lý cấu hình phần mềm vào qui trình sản xuất phần mềm của trung tâm. Hệ thống quản lý cấu hình phần mềm này sẽ không gây cản trở cho việc sản xuất phần mềm hiện tai đang được thực hiện ởn định như hiện nay.
• Tởng quát hóa hệ thống đã được xây dựng thành một hệ thống quản lý cấu hình phần mềm chung phù hợp những công ty phát triển phần mềm tương tự.
</div><span class="text_page_counter">Trang 20</span><div class="page_container" data-page="20"><b>Lý do tồn tại cấu hình phần mềm khác nhau: </b>
• Phần mềm chạy trên nhiều họ máy tính khác nhau. • Phần mềm chạy trên nhiều hệ điều hành khác nhau.
• Phần mềm chạy trên nhiều phiên bản khác nhau của các được phối hợp. • Phần mềm đáp ứng cho những ỵêu cầu cụ thể cho từng khách hàng.
Để quản lý được nhiều cấu hình khác nhau của cùng một phần mềm, các nhà phát triển thường sử dụng cây cấu hình phần mềm
</div><span class="text_page_counter">Trang 21</span><div class="page_container" data-page="21"><b>Hình 2-1 Cây cấu hình phần mềm </b>
Trong quá trình phát triển phần mềm, nhất là đối với những phần mềm lớn có nhiều tính năng, giao diện phức tạp và có sự tham gia của nhiều người thì việc quản lý những thay đởi của sớ lượng mã nguồn khổng lồ cùng với những tài liệu liên quan rất khó khăn và phức tạp. Vì vậy, một đồ án phần mềm sẽ gặp nhiều khó khăn trong việc báo cáo lại những gì mà nhà phát triển đang xây dựng, các thông tin về những sản phẩm đã làm gặp khó khăn hoặc không thể báo cáo được nếu không có sự quản lý chặt chẽ về nhân lực và mã nguồn hợp lý.
Một số câu hỏi thường được khách hàng hoặc chính người quản lý trong công ty đặt ra cho sản phẩm được phát triển cho mợt khách hàng:
• Có bao nhiêu sản phẩm đã được giao cho khách hàng?
• Với mỡi sản phẩm được giao thì sản phẩm đó đáp ứng được những yêu cầu nào của khách hàng?
• Sản phẩm đã giao được tích hợp từ những thành tố nào và những thông tin liên quan đến thành tố được tích hợp đó?
</div><span class="text_page_counter">Trang 22</span><div class="page_container" data-page="22">Đối với khách hàng, những thông tin trên sẽ giúp họ xác định được sản phẩm họ đang hoặc sẽ dùng có đáp ứng đúng nhu cầu của họ đã đặt ra hay không, những yêu cầu nào còn thiếu cần phát triển thêm hoặc chỉnh sửa những yêu cầu bị sai..
Đối với nhà sản xuất, những thông tin trên giúp họ xác định được đâu là sản phẩm đã giao cho khách hàng và đâu là sản phẩm đang phát triển trong nội bộ công ty. Và khi có thông tin phản hồi từ phía khách hàng họ sẽ biết được thông tin đó liên quan đến sản phẩm nào và phiên bản cụ thể của sản phẩm đó. Điều này giúp ích rất nhiều cho việc sản xuất phần mềm: đảm bảo chất lượng của phần mềm và rút ngắn thời gian sản xuất phần mềm.
Kết quả là có rất nhiều giải pháp về quản lý cấu hình phần mềm được ra đời để giúp cho các nhà phát triển phần mềm giải quyết những khó khăn mà họ gặp phải liên quan đến cấu hình phần mềm.
<b>2.3.1 Mức độ mong muốn và việc phân tích chi phí và lợi nhuận 2.3.1.1 Mức độ mong muốn = Phạm vi + mức độ mơ hình hố </b>
Lợi ích và chi phí gắn với Quản lý cấu hình có liên quan tới cấp mức độ mong muốn của ta. Mức độ chia làm hai khía cạnh: phạm vi và hình thức hoá.
<b>Phạm vi: là số đối tượng đặt dưới sự quản lý cấu hình. </b>
<b>Mức độ hình thức hố: là về điều khiển việc quản lý cấu hình thực hiện như </b>
</div><span class="text_page_counter">Trang 23</span><div class="page_container" data-page="23">• Đối với những đề án thơng thường, người ta thường trộn lẫn các mức độ hình thức: dùng hình thức thấp trong những hoạt động ban đầu (như lập trình), và mức độ hình thức cao hơn trong việc bảo trì các phiên bản giao. Mỗi công ty phải định nghĩa các mức độ hình thức và các trường hợp ứng với các mức độ hình thức.
<b>Mức độ hình thức hố và cơng cụ </b>
Một công cụ sẽ ứng với một mức độ hình thức. Đa số cơng cụ sẽ cung cấp mức hình thức tối thiểu, các mức độ hình thức cao hơn sẽ thực hiện theo quy trình bằng tay. Một vài cơng cụ uyển chuyển có khả năng cho phép lựa chọn nhiều loại mức độ hình thức tuỳ theo các thực thể cấu hình khác nhau.
<b>Sự mở rộng về phạm vi </b>
Mỗi một đề án có nhiều thực thể cấu hình tiềm năng. Nói chung, mỗi đối tượng tạo ra hoặc mua được thường đặt vào trong quản lý cấu hình. Tuy nhiên, điều này khơng phải hồn tồn có lợi, nó sẽ làm cho chi phí tăng lên.
Hình 2.2 mơ tả chi phí tổng cộng để quản lý cấu hình trong đề án. Các thực thể góp phần làm tăng chi phí dựa vào:
• Khi thực thể đặt dưới sự quản lý cấu hình (trục x là thời gian)
• Mức độ hình thức mà hệ thống quản lý cấu hình thực hiện đối với một thực thể (trục y là mức độ hình thức)
• Số lượng thực thể đặt dưới sự quản lý cấu hình (trục z mơ tả các thực thể cấu hình theo thời gian)
</div><span class="text_page_counter">Trang 24</span><div class="page_container" data-page="24"><b>Hình 2-2 Tổng chi phí của quản lý cấu hình </b>
Do đó, ta phải cân nhắc đưa các loại đối tượng nào vào hệ thống quản lý cấu hình cho phù hợp.
<b>2.3.2 Ví dụ </b>
Hai bảng ở dưới là các ví dụ về các hoạt động trong hệ thống với mức độ hình thức cao và thấp. Các mức độ hình thức áp dụng cho tất cả các thực thể cấu hình như tài liệu, file mã nguồn, hoặc phiên bản giao cho khác hàng.
Giả sử các công cụ được đăng ký các giao tác trong một thư viện được quản lý, tự tạo ra một file nhật ký (log file). Cách làm này thì thường bị hạn chế và thích hợp cho mức độ hình thức thấp. Ở hình thức cấp cao, các thao tác log sẽ được người điền vào. Điều này có vẻ như quản lý cấu hình trên giấy tờ, nhưng thật ra thì những logs này sẽ được lưu trữ bằng máy
</div><span class="text_page_counter">Trang 25</span><div class="page_container" data-page="25">• Gửi email về những sự kiện cho người chịu trách nhiệm về quản lý cấu hình và các thành viên trong bộ quản lý cấu hình
Đánh giá sự kiện Người chịu trách nhiệm quản lý cấu hình đảm bảo rằng: • Mọi sự kiện đăng ký được đánh giá bởi nhà sản xuất gốc
(hoặc những chuyên gia khác)
• Kết qủa đánh giá được gửi email đến bộ quản lý cấu hình Thay đổi quyết định Ban điều khiển cấu hình:
• Gửi những quyết định thay đổi tới nhà sản xuất bằng email Thực thể mới Nhà sản xuất:
• Chỉ ra những thành phần nào cần thêm mới
• Lấy một phiên bản cấu hình trước làm nền cho sự tạo ra sản phẩm mới thích hợp
• Đăng ký những siêu dữ liệu thật cần thiết với yêu cầu định dạng
• Thêm những thành phần mới vào thư viện điều khiển
<b>Bảng 2-1 Mơ tả những hoạt động với mức độ hình thức thấp </b>
</div><span class="text_page_counter">Trang 26</span><div class="page_container" data-page="26">phần khác có liên quan
Đồng ý Người chịu trách nhiệm đánh giá:
• Điền và ký chấp nhận một thực thể sẵn sàng đặt dưới sự quản lý cấu hình
Xem xét Nhà sản xuất
• Đưa sự chấp thuận về meatdata, thành phần cho người quản lý
Đưa vào nơi lưu trữ Người quản lý
• Đặt thực thể trong thư viện quản lý
• Quan tâm việc đăng ký và lưu trữ liên quan đến metadata Đưa ra yêu cầu Người sử dụng
• Viết ra yêu cầu cho người quản lý bao gồm thông tin ai sẽ sữ dụng những thành phần và với mục đích gì.
Tạo bảng phát hành để sử dụng
Sự kiện đánh giá Người chịu trách nhiệm quản lý cấu hình
• Sắp xếp những cách đánh giá đối với mỗi sự kiện Cơng việc của Ban
Quản lý cấu hình
Ban quản lý cấu hình • Họp
• Đánh giá mỗi sự kiện đăng ký
• Ghi nhận lại cách đánh giá với mỗi sự kiện đăng ký Thay đổi yêu cầu Ban quản lý cấu hình
</div><span class="text_page_counter">Trang 27</span><div class="page_container" data-page="27">Đồng ý thay đổi Người chịu trách nhiệm về chất lượng
• Điền và ký chấp nhận một thực thể sẳn sàng đặt dưới sự quản lý cấu hình
Chấp nhận thay đổi Ban quản lý cấu hình: • Họp
• Đánh giá mỗi chấp thuận
• Ghi lại tài liệu đánh giá của họ về thay đổi yêu cầu và dữ kiện đăng ký
Xem xét sự thay đổi
Nhà sản xuất
• Nộp việc đăng ký metadata, thực thể và chấp nhận thay đổi yêu cầu cho người quản lý với mỗi thực thể mới
Lưu trữ Nguời quản lý
• Thêm những thực thể trong thư viện quản lý
• Quan tâm đến việc đăng ký và lưu các dữ liệu quan hệ Liên lạc khi thay
</div><span class="text_page_counter">Trang 28</span><div class="page_container" data-page="28"><b>2.3.3 Cân nhắc lợi hại </b>
Quản lý cấu hình mang lại những điều có lợi như tiết kiệm thời gian, chất lượng tốt hơn, tiết kiệm chi phí. Quản lý cấu hình cũng mang cho ta yếu tố “bảo hiểm”: bằng cách đầu tư nhỏ, nhưng tránh được những tổn thất lớn
Để có được đúng cấp quản lý cấu hình trong một ngữ cảnh cụ thể, ta phải tính tốn lợi hại dựa trên các khoản có thể tiết kiệm và chi phí phát sinh tương ứng, so sánh giữa chi phí và lợi nhuận có được như mong muốn hay khơng.
Quy trình sau dành cho công ty hay đề án mới cài đặt và phát triển quản lý cấu hình
• Tạo ra danh sách các khoản tiết kiệm trong tương lai cho cơng ty/ đề án, bao gồm những đánh gía về kinh tế. Tính tốn lại với mỗi lần thay đổi
• Ước lượng chi phí khi dùng quản lý cấu hình. Ước tính lại với mỗi sự thay đổi
• Tập trung ưu tiên vào những cách có lợi cùng với chiến lược trọng tâm của cơng ty. Ví vụ chiến lược thơng thường tập trung vào sự thỏa mãn khách hàng, năng suất, chất lượng , v.v…
• Theo dõi để đảm bảo kiểm sốt tất cả chi phí và chi phí tiết kiệm như đã ước tính và dùng kinh nghiệm để ước tính trước khả năng trước khi nỡ lực cải tiến tiếp
</div><span class="text_page_counter">Trang 29</span><div class="page_container" data-page="29">• Sửa cùng một lỗi ở nhiều chỗ
• Thực hiện công việc sai cơ bản (dùng những yêu cầu cũ) • Lỗi đã sửa lại tiếp tục bị lỗi
• Có những chức năng khơng mong muốn • Khơng biết khách hàng đã nhận phiên bản nào
• Nâng cấp tự do vì khơng tương thích với cơng nghệ cũ • Có những đoạn code thừa
• Truyền đạt sai kiến thức cho những người mới
Việc tiết kiệm cũng tuỳ vào các kinh nghiệm xử lý vấn đề của công ty
Bảng dưới chỉ ra chi tiết các vấn đề ở trên và cách quản lý cấu hình giải quyết và những gợi ý đánh giá về mặt kinh tế
<b>hình </b>
<b>Giá trị kinh tế </b>
Cùng một lỗi được sửa– và những người khác nhau sẽ sửa các biến khác nhau trong sản phẩm
Kịp thời nhận ra tất cả các biến ảnh hưởng và sửa lỗi tại một thời điểm
− Tiết kiệm (n-1)x (thời gian phân tích và sửa lỗi của một thành phần trong n biến)
− Tiết kiệm thời gian di chuyển.
Do đó, có thể xử lý sản phẩm, cài đặt cho khách hàng cùng một lúc
Một thiết kế tạo ra dựa trên những yêu cầu đã cũ
Đăng ký tất cả các trạng thái và lịch sử của tất cả cá thực thể cấu hình
− Tiết kiệm thời gian dành cho những cái sai cơ bản.
− Có sự thỏa mãn của các nhân viên tham gia
</div><span class="text_page_counter">Trang 30</span><div class="page_container" data-page="30">Những lỗi cũ xuất hiện lại khi một phiên bản mới được giao cho khách hàng
Nhận biết được tất cả các phiên bản của những thành phần cấu cũng như tất cả những thay đổi từ phiên bản này sang phiên bản khác
− Tiết kiệm thời gian tìm kiếm và sửa những lỗi cũ
− Thỏa mãn được khách hàng vì chất lượng tốt hơn
Nhà thiết kế và lập trình viên giới thiệu những chức năng khơng có trong u cầu
Một chức năng có thể được theo dõi và chấp nhận trên hợp đồng/ hoặc cũng bao gồm đặc tả yêu cầu, thay đổi yêu cầu
− Tiết kiệm thời gian thực hiện (thiết kế, code,.. ) cho những chức năng không mong muốn
Lỗi ở sản phẩm giao cho khách hàng khó tìm thấy vì ta khơng biết đã giao cho khách hàng phiên bản nào
Biết được khách hàng đang sử dụng version nào
− Tiết kiệm thời gian xác định phiên bản giao cho khách hàng − Tiết kiệm thời gian và
chi phí
− Tiết kiệm được số tiền phải giảm giá cho khách hàng cho lần bán kế tiếp đối với cùng khách hàng vì lỗi − Tiết kiệm được tiền
phải trả do trể hẹn với khách hàng
− Thỏa mã khách hàng nhiều hơn vì dịch vụ tốt
</div><span class="text_page_counter">Trang 31</span><div class="page_container" data-page="31">Các phần mềm mới làm cho các khách hàng cũ. Vì ta khơng biết rõ phiên bản cũ có hoạt động được cùng với cơng cụ mới hay khơng. Do đó, để an tịan, ta phải cập nhật lại miễn phí các cơng cụ cũ
Thông tin về những lần thay đổi trong mỗi phiên bản và biết được khách hàng đã mua những phiên bản cũ nào.
− Tiết kiệm thời gian và công cụ để cập nhật những thiết bị cũ − Làm giảm sự mất thời
gian của khách hàng − Giảm thời gian cài đặt
Cùng một chức năng được phát triển lại trong một số đề án. Dù ta biết, nhưng ta lại khơng thể dùng lại vì mất thời gian tìm kiếm và chỉnh sửa lại mã nguồn đó đề cài đặt vào chức năng của sản phẩm khác
Dễ dàng tìm lại những thực thể nào được dùng lại
− Đánh giá việc phát triển mới những thành phần
− Tiết kiệm thời gian để làm cho những thực thể thích ứng với mơi trường mới
Một nhân viên mới phải làm quen với sản phẩm bằng cách đọc các tài liệu về sản phẩm. Tuy nhiên, tài liệu chưa được cập nhật, không ứng với mã nguồn hiện tại – Do đó, người nhân viên mới phải xem tất cả các mã nguồn !
Đăng ký các mối liên hệ giữa mã nguồn và những tài liệu tương ứng, những thay đổi, thời gian cập nhật
− Tiết kiệm thời gian dành cho những điều sai cơ bản
− Sự thỏa mãn của nhân viên
<b>Bảng 2-3 Ví dụ về tiết kiệm khi sử dụng hệ thống Quản lý cấu hình </b>
</div><span class="text_page_counter">Trang 32</span><div class="page_container" data-page="32"><b>2.3.4 Những bẫy kết hợp với phạm vi </b>
Khi tính tốn lợi hại, cần tinh tốn cân nhắc mức độ quản lý cấu hình như thế nào. Ta khơng nên chọn q nhiều địi hỏi, địi hỏi sai, quá chung chung, hoặc quá chi li, quá cứng nhắc, quá riêng, quá trễ, quá sớm
<b>2.3.5 Cách xứ lý các thứ khác ở bên ngoài </b>
Trong một đề án cụ thể, mỗi người sẽ chọn các đối tượng đặt dưới sự quản lý cấu hình khác nhau, tùy theo cách nhìn của mỗi người. Việc xử lý này không phải của hệ thống quản lý cấu hình mà của quản lý đề án, người quản lý.
<b>Những đối tượng lưu bên ngoài </b>
Những đối tượng không thường đặt dưới sự quản lý cấu hình thường bao gồm: • Những thứ khơng quan trọng tới việc giao sản phẩm hoàn tất (thư từ, những
tài liệu quản trị khác)
• Những thứ khơng bao giờ thay đổi (những lần họp mặt, trạng thái báo cáo) • Những cái có thể tạo lại (phiên bản phát hành đã được dịch hoặc những file
thực thi)
Trong trường hợp thứ ba, chúng ta cần xem xét cái nào thuận tiện hơn đặt vào quản lý cấu hình: cơng cụ dùng để tạo đối tượng hay những dẫn xuất của đối tượng (mã nguồn và trình biên dịch hay mã nguồn và module đã được dịch.).
<b>Định danh thớng nhất </b>
Có lợi cho ta nếu định nghĩa sự định danh quy nhất cho các đối tượng, thậm chí các đối tượng khơng được đặt dưới sự quản lý cấu hình.
<b>Lưu trữ </b>
Thậm chí một số đối tượng khơng nằm trong quản lý cấu hình cũng phải được cất ở một nơi nào đó. Ta cần có một thư viện khơng đặt duới sự kiểm sốt của quản lý cấu hình, nhưng vẫn phải nằm trong sự quản lý.
</div><span class="text_page_counter">Trang 33</span><div class="page_container" data-page="33">Một đề án phần mềm như một vở kịch, phải có những thành viên tham gia với ai trò lớn, nhỏ nhưng tất cả đều quan trọng.
Phần này nói về khía cạnh con người trong quản lý cấu hình. Khơng chỉ tập trung vào các cá nhân, mà còn các mối quan hệ của họ vào sự phát triển và bảo trì phần mềm. Phần này mơ tả tầm quan trọng của các vai trị đến cơng việc liên quan.
Các vai trị được sắp xếp có tổ chức và có thể thay đổi tùy cơng ty. Có thể một hay nhiều người chỉ đóng một vai trị, cũng như một người đóng nhiều vai trò.
<b>2.4.1 Con người và quản lý cấu hình </b>
Nhiều người gây ảnh hưởng và bị ảnh hưởng bởi quản lý cấu hình trong suốt quá trình phát triển và bảo trì phần mềm. Quản lý cấu hình có thể là cơng việc chính hoặc chỉ là một phần cơng việc trong cơng việc chính, ví dụ như cơng việc của lập trình viên và cơng việc quản lý đề án. Trong mỗi trường hợp, ta cần làm việc nhóm. Mỗi nhóm có mức độ ảnh hưởng nhất định đến kế hoạch thực hiện công việc.
<b>2.4.1.1 Quản lý cấu hình như là một nghề </b>
Nhiều người nghi ngờ tại sao xem quản lý cấu hình như là một nghề. Nhưng có thể những thách thức ở mặt kỹ thuật cũng thú vị như mặt quản lý. Nó mang lại cơ hội theo dõi được sản phẩm trong suốt vòng đời và biết được các cấp, các nhân viên tham gia, khách hàng, từ người quản lý cao cấp đến developer mới nhất.
Quản lý cấu hình có kỹ luật trong các quy trình. Ngành cơng nghiệp ngày càng nhận thức tầm quan trọng của những quy trình trưởng thành, có cấu trúc để cải tiến cơng việc. u cầu tăng về chất lượng, do đó cần nhiều người có kiến thức vững chắc và kinh nghiệm trong quản lý cấu hình.
</div><span class="text_page_counter">Trang 34</span><div class="page_container" data-page="34">• Chú ý vào chi tiết
• Phương pháp làm việc tỉ mỉ • Khéo léo
• Khả năng giao tiếp với nhiều loại người
• Có kiến thức tịan diện về quy trình phát triển phần mềm nói chung
<b>2.4.1.2 Quản lý cấu hình là công việc của mỗi người </b>
Quản lý cấu hình là một phần quen thuộc trong cuộc sống hàng ngày của những ai tham gia vào sự phát triển và bảo trì sản phẩm phần mềm. Những hoạt động này có thể chiếm ít hoặc nhiều thời gian của chúng ta, nhưng ai cũng có lợi với kết qủa đạt được và phải góp phần đóng góp vào q trình thực hiện.
Mỗi người trong đề án phải biết quy trình cấu hình nào tồn tại những hoạt động mà họ phải chịu trách nhiệm thực hiện.
<b>2.4.2 Các vai trò trong quản lý cấu hình </b>
Các vai trò chỉ ra ở đây là các vai trị chung để có thể áp dụng cho nhiều tổ chức, công ty. Trong thực tế, một số các vai trị nhất định trong các cơng ty ứng với một mức độ trưởng thành nhất định, nhưng cụ thể điều này lại cũng tùy thuộc vào sự xem xét, cân nhắc của cơng ty.
Những vai trị này khơng phải là những cơng việc tịan thời gian, tuy nhiên, nó khơng được dưới 25% cơng việc của một người, vì những nhiệm vụ cần phải liên hệ với những nhiệm vụ khác để thực hiện đúng công việc
<b>2.4.2.1 Ban quản lý cấu hình </b>
Ban quản lý cấu hình mang trách nhiệm kiểm sốt những thành phần cấu hình. Ban này chịu trách nhiệm về:
• Đánh giá các sự kiện đăng ký
• Tạo ra những thay đổi u cầu thích hợp
• Theo dõi các sự kiện đăng ký và thay đổi yêu cầu trong suốt quy trình phát triển
</div><span class="text_page_counter">Trang 35</span><div class="page_container" data-page="35">• Mang lại phản hồi cho người đăng ký những thay đổi cấu hình và những nhà thầu khốn khác
• Hợp tác với những ban quản lý cấu hình tương đương
• Hợp tác với quản lý đề án hoặc những người quản lý khác tương đương Vai trò của ban này là đại diện tất cả các hội đồng thầu khốn trong quản lý những thực thể cấu hình. Phải có một người chủ tịch để ra những quyết định – bao gồm các quyết định lớn về mặt kinh tế
Ban sẽ chịu trách nhiệm cho những thay đổi - ví dụ người quản lý đề án có thể biết hoặc chỉ ra thực thể cấu hình nào bị ảnh hưởng khi có một sự kiện được ghi nhận. Hoặc việc chọn ra một thành phần cấu hình có thể được phân tích sự ảnh hưởng việc thay đổi trên đề án.
Ban có thể gồm một người như người kiểm soát chất lượng nếu người này có khả năng đưa ra các quyết định đúng đắn.
Khi quản lý cấu hình có ảnh hưởng lớn hơn, ban này có thể gồm nhiều người như người quản lý đề án, người khảo sát hiện trạng khác hàng, người chịu trách nhiệm về chất lượng.
<b>Các kỹ năng và kiến thức yêu cầu </b>
Ban cấu hình sẽ quyết định cuối về việc đăng ký các sự kiện xảy ra. Đo đó, ban này phải có năng lực và đưa ra các quyết định cần thiết, đặc biệt, có những quyết định có thể khơng được sự đồng tình nhiều.
Ban này phải biết được mục đích của sản phẩm và liên hệ với những sản phẩm có liên quan, đồng thời có tầm nhìn của cơng ty để cho phép những thay đổi có khả năng. Ban này phải có kiến thức chung về quản lý cấu hình.
<b>Nhiều ban </b>
Một cơng ty có thể có nhiều hơn một ban, xử lý nhiều loại thành phần cấu hình và được liên kết với nhiều thành phần có tổ chức. Điều nay được minh hoạ ở hình dưới. Hình chỉ ra các thành phần cấu hình có thể ảnh hưởng đến nhiều ban khác như sản xuất, đề án, tịan cơng ty hoặc khách hàng. Tùy thuộc vào tầm ảnh
</div><span class="text_page_counter">Trang 36</span><div class="page_container" data-page="36">hưởng của thành phần, nhiều ban khác nhau có thể chịu trách nhiệm cho sự thay đổi. Hình dưới chỉ đứng ở khía cạnh tổ chức, khơng phải thời gian.
<b>Hình 2-3 Nhiều ban quản lý cấu hình </b>
Với mỗi ban, phải định nghĩa rõ ràng phạm vi trách nhiệm, những thành phần cấu hình liên quan tương ứng. Mọi sự trao đổi phải rõ ràng vì nếu khơng, một sự kiện xảy ra sẽ được xử lý khác nhau bởi các ban khác nhau.
<b>2.4.2.2 Người quản lý </b>
Người quản lý chịu trách nhiệm xây dựng thư việc quản lý cấu hình hoặc những thư viện cho việc lưu giữ đồng đồng bộ của mỗi thư viện, đồng bộ các thư viện với nhau. Người quản lý thư viện quan tâm đến cấu trúc (các kệ và các hệ thống mục lục) và việc thiết lập (gán nhãn và vị trí của các cuốn sách), khơng quan tâm đến nội dung cuốn sách vì nó thuộc về tác giả và nhà xuất bản.
Vai trò người quản lý thư viện giống như của nguời kế toán. Người này phải chắc tất cả các khía cạnh của quản lý cấu hình được sắp xếp và làm việc với nhau. Người giữ nhiệm vụ này phải đặc biệt chú ý về chi tiết và một phương pháp làm việc tỉ mỉ
</div><span class="text_page_counter">Trang 37</span><div class="page_container" data-page="37">Hoạt động của người quản lý thư vện phụ thuộc vào mức độ quản lý cấu hình được thực hiện như thế nào. Với mức độ hình thức cao, cơng việc thực hiện và giám sát bao gồm:
• Thiết lập thư viện quản lý cấu hình – quản lý hệ thống thư viện chính để chức các thành phần cấu hình
• Lưu trữ và quản lý nội dung của thư viện
+ Đặt các thực thể trong nơi lưu trữ dựa trên việc thực thể này được chấp nhận như thế nào
+ Tạo và bảo trì siêu dữ liệu
+ Lấy ra các thực thể để sử dụng dựa trên yêu cầu lấy ra + Lấy ra những thực thể để sản xuất
• Liên hệ với nội dung của thư viện quản lý cấu hình + Tạo ra các mẫu báo cáo
+ Rút thông tin và tạo các báo cáo
+ Rút trích thơng tin như việc đo các quy trình khác • Quản lý thư viện cấu hình
+ Quản lý việc tích hợp của siêu dữ liệu
+ Các hoạt động quản trị cơ sở dữ liệu thông thường như nén dữ liệu • Các hoạt động sao lưu dữ liệu
Khi mức độ hình thức thấp, nhiều các hoạt động thư viện được giao phó cho các vai trị khác. Người quản lý thư viện phải có kiến thức vững về quản lý cấu hình nói chung, và cách thực hiện, quyền hạn thực hiện trong công ty. Trong nhiều trường hợp, người quản lý thư viện sẽ hợp tác với người chịu trách nhiệm quản lý cấu hình hoặc quản lý quy trình để cải tiến quy trình của quản lý cấu hình
<b>2.4.2.3 Người chịu trách nhiệm quản lý cấu hình </b>
Người chịu quản lý cấu hình thực hiện, bảo trì, cải tiến quản lý cấu hình theo các nguyên tắc quản lý. Người này chịu trách nhiệm sử dụng các công cụ hỗ trợ
</div><span class="text_page_counter">Trang 38</span><div class="page_container" data-page="38">Người chịu trách nhiệm quản lý cấu hình phải có cách nhìn khác nhau về việc sắp xếp và các chi tiết cũng như các tóm tắt. Người này phải có khả năng giao tiếp với nhiều loại người – dù trong nhiều tình huống trái ngược
Người này phải am hiểu về quản lý cấu hình, về lý thuyết và kỹ thuật hiện tại. Hiều được nhu cầu của công ty và khả năng chuyển những mong muốn đo thành những quy trình thực tế. Có kiến thức về các ngun tắc: phân tích rủi ro, ước lượng, tính tốn lợi nhuận, độ đo, cũng như cập nhật những kiến thức liên quan đến kỹ thuật và cơng cụ có sẳn.
Hoạt động bao gồm:
• Chuyển nhu cầu của công ty và những yêu cầu sang quản lý cấu hình tương ứng, các quy trình thực tế, tài nguyên, và cơng cụ
• Chọn và kiểm thử các cơng cụ cấu hình phần mềm
• Cập nhật thông tin về các phiên bản mới của các công cụ tồn tại sẳn và những công cụ mới
• Theo dõi việc thực hiện và tính hiệu qủa của quản lý cấu hình
• Tạo ra các báo cáo với phân tích dữ liệu và đưa ra những đề nghị cải tiến Những vai trò khác, mức độ nhỏ hay lớn, việc tìm kiếm người chịu trách nhiệm quản lý cấu hình phụ thuộc vào cách phân chia các trách nhiệm và mức độ hình thức. Trong nhiều cơng ty, người này có thể có mối quan hệ gần với người chịu trách nhiệm về công cụ.
</div><span class="text_page_counter">Trang 39</span><div class="page_container" data-page="39"><b>2.4.2.4 Kế họach quản lý cấu hình </b>
Quản lý cấu hình phải là những hoạt động bao gồm trong lên kế hoạch và lập ngân sách cho một sản phẩm hoặc một đề án.
<b>2.4.3 Các vai trò trong tở chức </b>
Các vai trị ở đây mơ tả cấu trúc tổ chức thông thường của công ty. Mơ tả vai trị ở đây tập trung vào mối quan hệ với quản lý cấu hình.
<b>2.4.3.1 Quản lý </b>
Quản lý chịu trách nhiệm đảm bảo công ty có một quy định về quản lý cấu hình mà hỗ trợ hiệu qủa cho các mục đích của công ty. Quản lý sẽ xem xét cách quản lý cấu hình thực hiện như thế nào để có lợi nhất về chi phí
<b>Định nghĩa và theo dõi các mục đích </b>
Dựa trên kiến thức chung về quản lý cấu hình, thiết lập mục tiêu cho quản lý cấu hình và theo dõi việc thực hiện những mục tiêu này. Người chịu trách nhiệm cung cấp
• Hỗ trợ việc thực hiện và cải tiến quản lý cấu hình − Hỏi về kế hoạch quản lý cấu hình và theo dõi quy trình − Định hướng và định mức ưu tiên các tài nguyên cần thiết .. • Hỗ trợ cho các nhân viên làm việc với quản lý cấu hình − Tạo ra cơng việc và mộ tả các vai trị trong quản lý cấu hình − Các hoạt động quản lý cấu hình trong mơ tả các cơng việc khác − Định nghĩa tiềm năng công việc trong quản lý cấu hình với cơng ty
<b>Lợi ích </b>
Cơng ty có thể đạt lợi nhuận nếu thực hiện đúng quản lý cấu hình, người quản lý cấp cao có thể theo dõi các kế hoạch quan trọng và những bước phát triển mới nhất của các developer hoặc các trợ lý cấp cao có thể tìm và tin vào những quy trình mơ trong cơng việc của mình.
</div><span class="text_page_counter">Trang 40</span><div class="page_container" data-page="40"><b>2.4.3.2 Người chịu trách nhiệm với tài sản </b>
Vai trò này chịu trách nhiệm về các tài sản, hay các thành tố sử dụng lại, được tạo ra và dùng trong quá trình phát triển. Đảm bảo tài sản đáp ứng các yêu cầu mong muốn và lưu chúng dưới quản lý cấu hình. Quản lý các tài sản này là cần thiết vì những thay đổi có thể ảnh hưởng đến sản phẩm hoặc các đề án khác có liên quan.
Quản lý cấu hình phải được xem xét trong lúc lập kế hoạch và lên ngân sách trong tổ chức liên quan đến phát triển các tài sản hoặc các thành tố sử dụng lại. Vai trò này cần đảm bảo trong kế hoạch cung cấp các tài nguyên cần thiết cho những người tham gia và kiến trúc đề án.
Người giữa vai trò này cần có kiến thức vững về • Các ngun tắc về quản lý cấu hình nói chung • Cách cơng ty thực hiện quản lý cấu hình Cần chú ý:
• Phải chỉ ra mơ tả về Tài sản để dễ tìm kiếm.
• Đánh giá và chấp nhận các tài sản mới trên tiêu chuẩn chất lượng.
• Tất cả những người dùng các tài sản, khi tài sản có một phiên bản phát hành khác, các người dùng sẽ được thông báo chi tiết để cho người dùng quyết định sử dụng phiên bản mới hay phiên bản cũ.
<b>Nhiều mơ tả về quy trình khác nhau </b>
Quản lý cấu hình được thực hiện khác nhau trong nhiều nơi trong cơng ty. Sự khác nhau là do tính lịch sử và văn hố của cơng ty hoặc do việc định nghĩa của các công cụ. Mặc dù sự khác biệt này là khơng được mong muốn, nhưng nó vẫn xảy ra.
Ví dụ như các quy ước về định danh, các quy trình đưa sản phẩm vào nơi lưu trữ hoặc phát hành chúng để sử dụng. Do đó, người chịu trách nhiệm về tài sản phải cẩn thận khi đưa ra các mơ tả quy trình tương ứng.
<b>2.4.3.3 Người chịu trách nhiệm trong quá trình vận hành </b>
Người chịu trách nhiệm vận hành đảm bảo rằng sản phẩm tạo ra vận hành như mong muốn và quản lý cấu hình được thực hiện trong suốt quá trình vận hành.Việc
</div>