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
Trang 1LUẬN VĂN CỬ NHÂN TIN HỌC
GIÁO VIÊN HƯỚNG DẪN
TS TRẦN ĐAN THƯ Th.S NGUYỄN TRỌNG TÀI
TP HCM, 2004
Trang 4KHOA CNTT –
ĐH KHTN
Luận văn của chúng em sẽ rất khó hoà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 toà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 luôn 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 hoà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 quý 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
Trang 5KHOA CNTT –
ĐH KHTN
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
Chương 1: Mở đầu
Chương 2: Tổng quan về quản lý cấu hình phần mềm
Chương 3: Quản lý cấu hình phần mềm trong CMM & CMMI
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
pháp
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
Trang 6KHOA CNTT –
ĐH KHTN
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
Trang 7KHOA CNTT –
ĐH KHTN
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
Trang 86.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
Trang 9KHOA CNTT –
ĐH KHTN
7.1 Tự đánh giá 1657.2 Hướng phát triển 165
Trang 10KHOA CNTT –
ĐH KHTN Danh sách hình
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
Trang 11KHOA CNTT –
ĐH KHTN
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
Trang 12KHOA CNTT –
ĐH KHTN Danh sách bảng
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
Trang 13KHOA CNTT –
ĐH KHTN Một số khái niệm / thuật ngữ
Thuật ngữ dùng trong CMMI
STT Thuật ngữ Diễn giải
1
Process Areas (PA) – Vùng tiến trình
Vùng tiến trình (Process Areas PA): Mỗi PA là một
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
(SG) – Mục tiêu chuyên biệt
Mục tiêu chuyên biệt (Specific Goals - SG): Các
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 hoàn tất một vùng tiến trình nào đó hay không
3
Specific
Practices (SP) – Quy tắc thực tiễn chuyên biệt
Quy tắc thực tiễn chuyên biệt (Specific Practices – SP): Một quy tắc thực tiễn chuyên biệt là một hoạt
động đóng vai trò quan trọng để góp phần đạt được mục tiêu chuyên biệt tương ứng
4
Generic Goals (GG) – Mục tiêu tổng quát
Mục tiêu tổng quát (Generic Goals - GG): Các mục
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
Trang 14KHOA CNTT –
ĐH KHTN
Thuật ngữ về Quản lý cấu hình
STT Thuật ngữ Diễn giải
tra
Kiểm tra (Audit): kiểm tra một thực thể cấu hình
đượ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)
2
Baseline – Cấu hình cơ sở
Cấu hình cơ sở (Baseline): Là một tập hợp các yêu
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
3
trữ vào trong một thư viện được kiểm soát để tạo sản
phẩm
nơi lưu trữ sau khi check out
5
Configuration Control Board (CCB) – Ban quản lý cấu hình
Configuration Change Board – Ban kiểm soát thay đổi cấu hình
Ban quản lý cấu hình (Configuration Control Board), Ban kiểm soát thay đổi cấu hình
(Configuration Change Board) : Một nhóm người
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
thay đổi
item – Thực
Thực thể cấu hình (Configuration item): Một sản
phẩm công việc trung gian, các thành tố (component)
Trang 15Hệ thống quản lý cấu hình (Configuration management system): Tất cả các định nghĩa quy
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ể
Siêu dữ liệu (Metadata): Thông tin về các thực thể
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 đó
11
Procedure – Quy trình
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ố
định
12
Process – Tiến trình
Tiến trình (Process): Mô tả cách sử dụng các thông
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
13
Process
description – Mô tả tiến trình
Mô tả tiến trình (Process description): Mô tả các
kỹ thuật, phương pháp, các quy ước, các quy trình
liên hệ với một hoạt động nào đó
14
Product – Sản phẩm
Sản phẩm (Product): có thể là sản phẩm sử dụng
nội bộ hay là sản phẩm được phát hành ra bên ngoài
cho khách hàng
Trang 16Phiên bản (Version): Là một thể hiện của phần
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 hoàn toà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
17
Support
process – Quy trình hỗ trợ
Quy trình hỗ trợ (Support process): Quy trình
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ì
cả Nó chỉ có ý nghĩa khi được dùng với một quy
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
Trang 17KHOA CNTT –
ĐH KHTN Chương 1 Mở đầu
1.1 Quản lý cấu hình phần mềm trên thế giới và ở Việt Nam
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 toà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ụ
Trang 181.2 Các công cụ hỗ trợ quản lý cấu hình hiện tại
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)
1.3 Mục tiêu đề tài
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
Trang 19KHOA CNTT –
ĐH KHTN
• 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ự
Trang 20KHOA CNTT –
ĐH KHTN Chương 2 Tổng quan về quản lý cấu hình phần
Lý do tồn tại cấu hình phần mềm khác nhau:
• 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
Trang 21KHOA CNTT –
ĐH KHTN
Hình 2-1 Cây cấu hình phần mềm
2.2 Nguồn gốc hình thành của quản lý cấu hình
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 đó?
Trang 22KHOA CNTT –
ĐH KHTN
Đố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
2.3 Phạm vi và nhiệm vụ của quản lý cấu hình
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 hoá
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á
Phạm vi: là số đối tượng đặt dưới sự quản lý cấu hình
Mức độ hình thức hoá: là về điều khiển việc quản lý cấu hình thực hiện như
Trang 23KHOA CNTT –
ĐH KHTN
• Đố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
Mức độ hình thức hoá và công cụ
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
Sự mở rộng về phạm vi
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 hoàn toà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)
Trang 24KHOA CNTT –
ĐH KHTN
Hình 2-2 Tổng chi phí của quản lý cấu hình
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
2.3.2 Ví dụ
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
Trang 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ảng 2-1 Mô tả những hoạt động với mức độ hình thức thấp
Trang 26KHOA CNTT –
ĐH KHTN
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
Trang 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
Trang 28KHOA CNTT –
ĐH KHTN
2.3.3 Cân nhắc lợi hại
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 toá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 toá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 soá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
Trang 29KHOA CNTT –
ĐH KHTN
• 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ế
hình
Giá trị kinh tế
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
Trang 30KHOA CNTT –
ĐH KHTN
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 yê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
Trang 31KHOA CNTT –
ĐH KHTN
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ảng 2-3 Ví dụ về tiết kiệm khi sử dụng hệ thống Quản lý cấu hình
Trang 32KHOA CNTT –
ĐH KHTN
2.3.4 Những bẫy kết hợp với phạm vi
Khi tính toán lợi hại, cần tinh toá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 quá 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
2.3.5 Cách xứ lý các thứ khác ở bên ngoài
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ý
Những đối tượng lưu bên ngoài
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.)
Định danh thống nhất
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
Lưu trữ
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 soát của quản lý cấu hình, nhưng vẫn phải nằm trong sự quản lý
Trang 33KHOA CNTT –
ĐH KHTN
2.4 Các vai trò trong quản lý cấu hình phần mềm
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ò
2.4.1 Con người và quản lý cấu hình
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
2.4.1.1 Quản lý cấu hình như là một nghề
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 Yê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
Trang 34KHOA CNTT –
ĐH KHTN
• 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
2.4.1.2 Quản lý cấu hình là công việc của mỗi người
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 quá 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
2.4.2 Các vai trò trong quản lý cấu hình
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
2.4.2.1 Ban quản lý cấu hình
Ban quản lý cấu hình mang trách nhiệm kiểm soá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 yê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
Trang 35KHOA CNTT –
ĐH KHTN
• 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 khoá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 khoá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
Các kỹ năng và kiến thức yêu cầu
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
Nhiều ban
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
Trang 36KHOA CNTT –
ĐH KHTN
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
Hình 2-3 Nhiều ban quản lý cấu hình
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
2.4.2.2 Người quản lý
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ỉ
Trang 37KHOA CNTT –
ĐH KHTN
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
2.4.2.3 Người chịu trách nhiệm quản lý cấu hình
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ợ
Trang 38Ngườ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 nguyên tắc: phân tích rủi ro, ước lượng, tính toá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ụ
Trang 39KHOA CNTT –
ĐH KHTN
2.4.2.4 Kế họach quản lý cấu hình
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
2.4.3 Các vai trò trong tổ chức
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
2.4.3.1 Quản lý
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í
Định nghĩa và theo dõi các mục đích
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
Lợi ích
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
Trang 40KHOA CNTT –
ĐH KHTN
2.4.3.2 Người chịu trách nhiệm với tài sản
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 nguyên 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ũ
Nhiều mô tả về quy trình khác nhau
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 hoá 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
2.4.3.3 Người chịu trách nhiệm trong quá trình vận hành
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