Luận văn: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

TRƯỜNG ĐẠI HỌC KHOA HỌC TỰ NHIÊN TP.HỒ CHÍ MINH

KHOA CÔNG NGHỆ THÔNG TIN

BỘ MÔN CÔNG NGHỆ PHẦN MỀM

HỒ NGUYỄN NGỌC PHƯƠNG – 0012076

TRIỆU NGỌC TOÀN

– 0012105

QUẢN LÝ CẤU HÌNH PHẦN MỀM

TẠI PHÒNG PHÁT TRIỂN PHẦN MỀM

QUANG TRUNG – TRUNG TÂM TIN HỌC

LUẬ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 TRỌNG TÀI

TP. HCM, 2004

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

..................................................................................................................................

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

..................................................................................................................................

Lời cám ơn

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

Trọng Tà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.

Tp.HCM, 7/2004

Nhóm sinh viên thực hiện

Hồ Nguyễn Ngọc Phương – Triệu Ngọc Toàn

Lời nói đầu

Hiện nay, công nghệ thông tin được xem là một trong những ngành công nghệ

mũi nhọn được nhà nước ta ưu tiên phát triển đặc biệt là lĩnh vực công nghệ phần

mềm. Tuy nhiên, lĩnh vực công nghệ phần mềm của nước ta vẫn còn khá non trẻ so

với nền công nghệ phần mềm của thế giới. Nên trong giai đọan hiện nay, các công

ty phần mềm thường gặp rất nhiều khó khăn liên quan đến qui trình phát triển phần

mềm.

Quản lý cấu hình phần mềm vốn là một vấn đề rất được quan tâm trong qui

trình sản xuất phần mềm. Hiện nay, qui trình quản lý cấu hình phần mềm tại phòng

phát triển phần mềm trực thuộc trung tâm tin học trường Đại Học Khoa Học Tự

Nhiên Tp. Hồ Chí Minh vẫn chưa được hoàn chỉnh. Do đó, việc hoàn thiện một hệ

thống quản lý cấu hình ở đây là cần thiết cho quá trình sản xuất phần mềm hiện tại

được thuận tiện hơn và chuẩn bị cho việc thực các đề án phần mềm lớn sau này đạt

hiệu qủa cao.

Từ nhu cầu nói trên, chúng em đã tiến hành thực hiện đề tài “Quản lý cấu hình

phần mềm tại phòng phát triển phần mềm Quang Trung – Trung tâm tin học”.

Nhằm mục đích cùng với phòng phát triển phần mềm thiết lập một hệ thống quản lý

cấu hình tốt có thể áp dụng vào quá trình sả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: Các công cụ hỗ trợ quản lý cấu hình phần mềm

Chương 6: Ứng dụng Software Version Management

Chương 7: Tổng kết

Mục Lục

Chương 1 Mở đầu ..................................................................................................1

1.1 Quản lý cấu hình phần mềm trên thế giới và ở Việt Nam .............................1

1.2 Các công cụ hỗ trợ quản lý cấu hình hiện tại.................................................2

1.3 Mục tiêu đề tài................................................................................................2

Chương 2 Tổng quan về quản lý cấu hình phần mềm ...........................................4

2.1 Khái niệm.......................................................................................................4

2.2 Nguồn gốc hình thành của quản lý cấu hình..................................................5

2.3 Phạm vi và nhiệm vụ của quản lý cấu hì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 Ví dụ......................................................................................................8

2.3.3 Cân nhắc lợi hại ..................................................................................12

2.3.4 Những bẫy kết hợp với phạm vi .........................................................16

2.3.5 Cách xứ lý các thứ khác ở bên ngoài ..................................................16

2.4 Các vai trò trong quản lý cấu hình phần mềm .............................................17

2.4.1 Con người và quản lý cấu hình ...........................................................17

2.4.2 Các vai trò trong quản lý cấu hình ......................................................18

2.4.3 Các vai trò trong tổ chức.....................................................................23

2.4.4 Các vai trò liên quan đến đề án...........................................................28

2.4.5 Các vai trò bên ngoài ..........................................................................35

2.5 Dữ liệu cho quản lý cấu hình .......................................................................36

2.5.1 Cái gì được đưa vào quản lý cấu hình ................................................36

2.5.2 Những điều cần biết về một thành phần cấu hình...............................44

2.6 Hệ thống quản lý cấu hình phần mềm .........................................................53

2.6.1 Khái niệm:...........................................................................................53

2.6.2 Mục tiêu ..............................................................................................54

2.6.3 Lợi ích .................................................................................................54

2.6.4 Các tiến trình con trong quản lý cấu hình phần mềm .........................54

Chương 3 Quản lý cấu hình phần mềm trong CMM & CMMI...........................56

3.1 Mô hình trưởng thành ..................................................................................56

3.2 CMM version 1.1 .........................................................................................56

3.2.1 Mức độ trưởng thành của CMM Version 1.1 .....................................56

3.2.2 Quản lý cấu hình phần mềm trong CMM version 1.1 ........................57

3.3 Quản lý cấu hình trong CMMI.....................................................................59

3.3.1 Các mức trưởng thành của CMMI ......................................................59

3.3.2 Quản lý cấu hình trong CMMI ...........................................................60

Chương 4 Vấn đề định danh, quản lý phiên bản và các giải pháp.......................76

4.1 Đặt tên các đối tượng cấu hình ....................................................................76

4.1.1 Đặt tên phân cấp dựa theo cấu trúc cây. .............................................76

4.1.2 Đặt tên phân cấp dựa theo phương pháp tiền tố và hậu tố..................77

4.1.3 Nhận xét chung ...................................................................................79

4.2 Xác định và định danh phiên bản.................................................................79

4.2.1 Sơ đồ tuyến tính ..................................................................................80

4.2.2 Sơ đồ định danh theo mạng. ...............................................................80

4.2.3 Sơ đồ định danh theo tên.....................................................................81

Chương 5 Các công cụ hỗ trợ quản lý cấu hình...................................................82

5.1 Tóm tắt .........................................................................................................82

5.2 Tính năng chung của Surround SCM và CVS .............................................82

5.3 Surround SCM .............................................................................................82

5.3.1 Mục đích .............................................................................................82

5.3.2 Cấu trúc của chương trình...................................................................83

5.4 CVS và CVSNT ...........................................................................................84

5.4.1 Mục đích .............................................................................................84

5.4.2 Cấu trúc của CVSNT ..........................................................................84

Chương 6 Ứng dụng minh họa “System Version Management” ........................86

6.1 Phân tích hiện trạng phát triển phần mềm tại T3H ......................................86

6.2 Đặc tả yêu cầu của hệ thống mới .................................................................95

6.3 Mô hình UseCase .........................................................................................99

6.4 Đặc tả usecase ..............................................................................................99

6.4.1 Đặc tả UseCase : Đăng Nhập (Login) ................................................99

6.4.2 Đặc tả UseCase : Thêm/xoá kho chứa ..............................................101

6.4.3 Đặc tả UseCase : Thêm/xoá đề án ....................................................102

6.4.4 Đặc tả UseCase : Cập nhật cấu trúc đề án ........................................104

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 trúc hệ thống.............................................................................118

6.5.2 Giao diện ...........................................................................................118

6.5.3 Mô hình lớp đối tượng ......................................................................123

6.5.4 Mô hình dữ liệu.................................................................................144

6.6 Mô hì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

6.6.6 Check out ..........................................................................................160

6.6.7 Check in ............................................................................................161

6.6.8 Gán nhãn cho Item ............................................................................162

6.6.9 Thiết lập quan hệ giữa hai versionfile...............................................163

6.6.10 Xem lịch sử của Item ....................................................................164

Chương 7 Tổng kết ............................................................................................165

7.1 Tự đánh giá ................................................................................................165

7.2 Hướng phát triển ........................................................................................165

Danh sách hì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 các mức trưởng thành của CMMI..............................................................59

Hình 4-1 Cây phân cấp đặt tên..................................................................................77

Hình 4-2 Sơ đồ định danh theo mạ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 trò của nhân viên trong hệ thống................................92

Hình 6-3 Cây phân cấp theo cấu trúc ........................................................................93

Hình 6-4 Cây phân cấp theo phân hệ / kiến trú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 trúc về phần cứng hệ thống .............................................................118

Hình 6-7 Màn hình chính ........................................................................................119

Hình 6-8 Màn hình thiết lập mối quan hệ giữa các tập tin......................................120

Hình 6-9 Màn hình thiết lập kiến trúc từ cấu trúc...................................................121

Hình 6-10 Màn hình xem thông tin của project, kho chứa, thư mục ......................121

Hình 6-11 Màn hình xem thông tin của tập tin và phiên bản của nó.....................122

Trang i

Hình 6-12 Màn hình xem lịch sử của tập tin, thư mục, project .............................122

Hình 6-13 Mô hình lớp đối tượng ...........................................................................123

Hình 6-14 Mô hình dữ liệu của hệ thống ................................................................144

Trang ii

Danh sách bả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 giải từ viết tắt cho qui tắc đặt tên .....................................................78

Trang iii

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

Vùng tiến trình (Process Areas PA): Mỗi PA là một Process Areas nhóm các hoạt động thực tiễn có liên hệ với nhau, 1. (PA) – Vùng nhằm để đạt được một số mục tiêu quan trọng của việc tiến trình cải tiến quy trình phần mềm

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 Specific Goals 2. gì cầm triển khai để thoả mãn vùng tiến trình đó. (SG) – Mục tiêu

Những mục tiêu này cũng được dùng trong việc đánh chuyên biệt

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

Specific 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 Practices (SP) – 3. động đóng vai trò quan trọng để góp phần đạt được Quy tắc thực

mục tiêu chuyên biệt tương ứng tiễn chuyên biệt

Mục tiêu tổng quát (Generic Goals - GG): Các mục Generic Goals tiêu tổng quát được gọi là “tổng quát” bởi vì cùng một 4. (GG) – Mục khẳng định được xuất hiện trong nhiều vùng tiến trình tiêu tổng quát khác nhau.

Quy tắc thực tiễn tổng quát (Generic Practices -

GP): Các quy tắc thực tiễn tổng quát cung cấp một cơ Generic 5. chế đảm bảo các tiến trình tương ứng với các vùng tiến Practices - GP

trình sẽ hiệu qủa, có thể lặp lại và bền vững

Trang iv

Thuật ngữ về Quản lý cấu hình

STT Thuật ngữ Diễn giải

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 Audit – Kiểm 1. tả yêu cầu. (Áp dụng trong hoạt động quản lý chất tra

lượng)

Cấu hình cơ sở (Baseline): Là một tập hợp các yêu Baseline – Cấu

cầu, thiết kế, mã nguồn, các tập tin định nghĩa tham hình cơ sở 2. 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

Check-out :Lấy ra một thực thể cấu hình từ nơi lưu Check-out

3. trữ vào trong một thư viện được kiểm soát để tạo sản

phẩm.

Check-in: Cập nhật lại một thực thể cấu hình từ vào Check in 4. nơi lưu trữ sau khi check out.

Configuration Ban quản lý cấu hình (Configuration Control

Control Board Board), Ban kiểm soát thay đổi cấu hình

(Configuration Change Board) : Một nhóm người (CCB) – Ban

chịu trách nhiệm sở hữu, chấp nhận hoặc từ chối, quản lý cấu

đưa ra đề nghị thay đổi đối với thực thể cấu hình và hình.

5. chịu trách nhiệm về việc thực hiện, phê duyệt các Configuration

thay đổi Change Board

– Ban kiểm

soát thay đổi

cấu hình

Thực thể cấu hình (Configuration item): Một sản Configuration 6. phẩm công việc trung gian, các thành tố (component) item – Thực

Trang v

hoặc sản phẩm được đặt dưới quản lý cấu hình thể cấu hình

Configuration Hệ thống quản lý cấu hình (Configuration

management system): Tất cả các định nghĩa quy management

7. trình, các biểu mẫu, các công cụ thu thập để hỗ trợ system – Hệ

quản lý cấu hình trong một môi trường cụ thể thống quản lý

cấu hình

Sự kiện (Event): Các sự kiện quan trọng xảy ra mà Event – Sự 8. ta cần chú ý, theo dõi. kiện

Thư viện (Library): Kho chứa chứa các thực thể Library – Thư 9. viện

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 Metadata – 10. hình là một thực thể cấu hình, trong khi tên và số của Siêu dữ liệu

tài liệu là siêu dữ liệu về thực thể tài liệu đó.

Procedure – Quy trình (Procedure): Số lượng các hoạt động

11. theo thứ tự với các thông tin đầu vào và đầu ra cố Quy trình

định

Tiến trình (Process): Mô tả cách sử dụng các thông Process – Tiến

tin đầu vào để tạo ra kết qủa đầu ra như mong muốn. trình

12. 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

Process Mô tả tiến trình (Process description): Mô tả các description – 13. kỹ thuật, phương pháp, các quy ước, các quy trình Mô tả tiến liên hệ với một hoạt động nào đó. trình

Sản phẩm (Product): có thể là sản phẩm sử dụng Product – Sản

nội bộ hay là sản phẩm được phát hành ra bên ngoài 14. phẩm

cho khách hàng

Trang vi

Phiên bản phát hành (Release): Là một thực thể Release - Phiên 15. cấu hình được tạo thành từ các thực thể cấu hình bản phát hành khác. Phiên bản này được phân phối cho khách hàng.

Phiên bản (Version): Là một thể hiện của phần Version -

mềm mà có sự thay đổi so với các thể hiện khác của Phiên bản

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

16. 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.

Quy trình hỗ trợ (Support process): Quy trình Support

dùng trong tất cả các quy trình khác tại các thời điểm process – Quy

khác nhau trong vòng đời của đế án phần mềm. trình hỗ trợ

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 17. 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 vii

Chương 1 - Mở đầu

Chương 1 Mở đầu

1.1 Quản lý cấu hình phần mềm trên thế giới và ở Việt Nam

Quản lý cấu hình phần mềm - SCM - là một tiến trình trong quá trình phát

triển phần mềm xuất hiện cách đây hơn 20 năm (vào khoảng năm 1980). Tiến trình

này giúp cho các nhà phát triển phần mềm kiểm sóat được những thay đổi và kiến

trúc của hệ thống phần mềm đang phát triển.

Vào giai đọan mới hình thành tiến trình quản lý phần mềm chủ yếu được thực

hiện đơn lẻ bởi những công ty phần mềm. Tuy nhiên, hầu hết các công ty đều nhận

thấy công việc quản lý sự thay đổi của phần mềm là vô cùng phức tạp và tốn kém.

Chính vì vậy, đã xuất hiện các công ty chuyên cung cấp các giải pháp chọn gói về

quản lý cấu hình phần mềm và các công cụ để hỗ trợ cho tiến trình này. Ví dụ:

Rational, Seapine, ...

Hiện nay, Tiến trình quản lý cấu hình phần mềm đã được viện nghiên cứu

công nghệ phần mềm SEI tổ chức và sắp xếp lại các họat động của tiến trình này

trở thành một phần của CMM và CMMI . Đồng thời cung cấp nhiều tài liệu hướng

dẫn việc thực hiện và áp dụng tiến trình này vào quá trình phát triển phần mềm

chung. Từ đó, các công ty phần mềm cảm thấy việc quản lý cấu hình phần mềm trở

nên rõ ràng hơn và các công ty hay tổ chức cá nhân chuyên về giải pháp quản lý cấu

hình phần mềm đã phát triển ra các công cụ riêng lẽ hỗ trợ cho từng bước của tiến

trình CM hay toàn bộ.

Trên thế giới, các công ty phần mềm lớn như Microsoft hoặc IBM, Oracle ...

đã tiến hành xây dựng tiến trình quản lý cấu hình phần mềm riêng của mình nhờ

vào kinh nghiệm phát triển của chính họ và sự tư vấn của các chuyên gia từ các viện

nghiên cứu phần mềm như S.E.I hay S.E.L và phát triển các công cụ riêng phục vụ

cho tiến trình này. Với các công ty nhỏ ít vốn và kinh nghiệm thì mua các công cụ

Trang 1

Chương 1 - Mở đầu

sẵn và áp dụng linh họat các qui trình chuẩn được công bố vào quá trình phát triển

phần mềm.

Ở Việt Nam, nền công nghệ phần mềm vẫn chưa thực sự phát triển mạnh,

phần lớn là các công ty nhỏ chuyên thực hiện các đề án về tin học hóa cho các cơ

quan, xí nghịêp hoặc gia công phần mềm cho nước ngoài và quá trình phát triển

phần mềm chỉ dựa trên kinh nghiệm với những phần mềm nhỏ và việc quản lý,

kiểm sóat tiến trình phát triển phần mềm ít được để ý. Chỉ có một vài công ty phát

triển nổi bật và đã đạt được những chuẩn về phát triển: FTP đạt CMM level 5, PSV

đạt CMM level 2... Thời gian gần đây, các công ty nhỏ đang dần dần tự cải tiến

mình để có thể thực hiện được những đề án phần mềm lớn trong và ngoài nước. Tuy

nhiên, làm cách nào để có thể dụng tốt các công cụ và giải pháp hiện có vào hoàn

cảnh thực tế ở Việt Nam là một điều không dễ dàng chút nào.

1.2 Các công cụ hỗ trợ quản lý cấu hình hiện tại

Hiện tại, các công cụ hỗ trợ cho việc quản lý quy trình sản xuất phần mềm

xuất hiện ngày càng nhiều. Một số công cụ đã xuất hiện từ lâu và được hoàn thiện

dần nên có chất lượng rất tốt. Chẳng hạn như các công cụ quản lý phần mềm

thương mại Clear Case của hãng Rational Rose hỗ trợ cho qui trình phát triển phần

mềm RUP, Surround SCM và Test Track Pro Intergration của hãng Seapine ...

thường có chi phí cao và được áp dụng cho các đề án phần mềm lớn hoặc các công

ty lớn già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 Mục tiêu đề tài

Mục tiêu của đề được đặt ra liên quan đến qui trình quản lý cấu hình tại phòng

phát triển phần mềm Quang Trung – Trung tâm tin học.

Các công việc chính mà đề tài cần phải giải quyết:

• Tìm hiểu về các phương pháp quản lý cấu hình và các kỹ thuật cụ thể được

dùng trong quản lý cấu hình

Trang 2

Chương 1 - Mở đầu

• Tìm hiểu một số công cụ hỗ trợ cho việc quản lý cấu hình.

• Tìm hiểu hiện trạng và qui trình sản xuất phần mềm của phòng phát triển

phần mềm trung tâm tin học.

• Xác định các yêu cầu cần phải thực hiện và các thông tin cần phải quản lý

để hỗ trợ cho cho qui trình phát triển mà trung tâm đang mong muốn xây

dựng trên qui trình hiện tại.

• Đưa ra các giải pháp về phần mềm để hỗ trợ qui trình đó và thay thế một số

phần mềm đang đang sử dụng bằng những phần mềm bằng những phần

mềm khác tương đương nhưng có những chức năng hỗ trợ khác hoặc xây

dựng một phần mềm mới phối hợp với các phần mềm hiện có hay thêm

mới.

• Triển khai việc áp dụng hệ thống quản lý cấu hình phần mềm vào qui trình

sản xuất phần mềm của trung tâm. Hệ thống quản lý cấu hình phần mềm

này sẽ không gây cản trở cho việc sản xuất phần mềm hiện tai đang được

thực hiện ổn định như hiện nay.

• Tổng quát hóa hệ thống đã được xây dựng thành một hệ thống quản lý cấu

hình phần mềm chung phù hợp những công ty phát triển phần mềm tương

tự.

Trang 3

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Chương 2 Tổng quan về quản lý cấu hình phần

mềm

2.1 Khái niệm

Quản lý cấu hình phần mềm là tiến trình kiểm sóat, theo dõi các thay đổi của

một hệ thống phần mềm và quản lý các phiên bản khác nhau của phần mềm đó.

Quản lý cấu hình phần mềm liên quan nhiều đến quá trình phải triển và bảo trì

sản phẩm phần mềm trong qui trình phát triển phần mềm.

Cấu hình của một phần mềm có thể xem như là một tập hợp các thành phần

con được tổ chức và phối hợp với nhau đáp ứng một yêu cầu hoặc một số yêu cầu

cụ thể nào đó.

Lý do tồn tại cấu hình phần mềm khác nhau:

• Phần mềm chạy trên nhiều họ máy tính khác nhau.

• Phần mềm chạy trên nhiều hệ điều hành khác nhau.

• Phần mềm chạy trên nhiều phiên bản khác nhau của các được phối hợp.

• Phần mềm đáp ứng cho những ỵêu cầu cụ thể cho từng khách hàng.

Để quản lý được nhiều cấu hình khác nhau của cùng một phần mềm, các nhà

phát triển thường sử dụng cây cấu hình phần mềm

Trang 4

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Hình 2-1 Cây cấu hình phần mềm

2.2 Nguồn gốc hình thành của quản lý cấu hình

Trong quá trình phát triển phần mềm, nhất là đối với những phần mềm lớn có

nhiều tính năng, giao diện phức tạp và có sự tham gia của nhiều người thì việc quản

lý những thay đổi của số lượng mã nguồn khổng lồ cùng với những tài liệu liên

quan rất khó khăn và phức tạp. Vì vậy, một đồ án phần mềm sẽ gặp nhiều khó khăn

trong việc báo cáo lại những gì mà nhà phát triển đang xây dựng, các thông tin về

những sản phẩm đã làm gặp khó khăn hoặc không thể báo cáo được nếu không có

sự quản lý chặt chẽ về nhân lực và mã nguồn hợp lý.

Một số câu hỏi thường được khách hàng hoặc chính người quản lý trong công

ty đặt ra cho sản phẩm được phát triển cho một khách hàng:

• Có bao nhiêu sản phẩm đã được giao cho khách hàng?

• Với mỗi sản phẩm được giao thì sản phẩm đó đáp ứng được những yêu cầu

nào của khách hàng?

• Sản phẩm đã giao được tích hợp từ những thành tố nào và những thông tin

liên quan đến thành tố được tích hợp đó?

Trang 5

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Đối với khách hàng, những thông tin trên sẽ giúp họ xác định được sản phẩm

họ đang hoặc sẽ dùng có đáp ứng đúng nhu cầu của họ đã đặt ra hay không, những

yêu cầu nào còn thiếu cần phát triển thêm hoặc chỉnh sửa những yêu cầu bị sai..

Đối với nhà sản xuất, những thông tin trên giúp họ xác định được đâu là sản

phẩm đã giao cho khách hàng và đâu là sản phẩm đang phát triển trong nội bộ công

ty. Và khi có thông tin phản hồi từ phía khách hàng họ sẽ biết được thông tin đó liên

quan đến sản phẩm nào và phiên bản cụ thể của sản phẩm đó. Điều này giúp ích rất

nhiều cho việc sản xuất phần mềm: đảm bảo chất lượng của phần mềm và rút ngắn

thời gian sản xuất phần mềm.

Kết quả là có rất nhiều giải pháp về quản lý cấu hình phần mềm được ra đời để

giúp cho các nhà phát triển phần mềm giải quyết những khó khăn mà họ gặp phải

liên quan đến cấu hình phần mềm.

2.3 Phạm vi và nhiệm vụ của quản lý cấu hì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ư

thế nào.

Ta khó mô tả chính xác được phạm vi hay hình thức nào là tốt nhất vì nó tùy

vào những yêu cầu và tình trạng thực tế

Mức độ hình thức hoá

Nhìn chung, mức độ hình thức trong mỗi đề án và mỗi công ty là khác nhau.

• Mức độ hình thức cao dành cho các hệ thống với tính an toàn cao.

• Những hệ thống khác chỉ cần mức độ hình thức thấp hơn miễn sao đạt

những yêu cầu mong muốn cơ bản.

Trang 6

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Đố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 7

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

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 Ví dụ

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

Hoạt động Mô tả

Tạo ra các thực thể Nhà sản xuất:

• Chỉ ra thực thể mới

• Đăng ký những dữ liệu cần nhất trong metadata

• Thêm thực thể mới trong thư viện được quản lý

Trang 8

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Sử dụng Người sử dụng:

• Trích ra việc sao chép các thực thể cấu hình khi cần.

Người sử dụng thực hiện trực tiếp từ thư viện quản lý

Các sự kiện Những người dùng:

• 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

Hoạt động Mô tả

Tạo ra thực thể mới Người chịu trách nhiệm quản lý cấu hình

• Chỉ ra thực thể mới

• Điền thông tin cần thiết đối với thực thể mới, bao gồm

những thông tin chi tiết tới mối quan hệ với các thành

Trang 9

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

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 Người quản lý

để sử dụng • Tạo ra những bản copy của thực thể cấu hình tới những

người dùng những thành phần này tùy theo yêu cầu

• Quan tâm đến việc đăng ký và lưu lại các dữ liệu có quan

hệ với nhau

Các sự kiện Những người dùng:

• Giao bảng đăng ký cho người có trách nhiệm quản lý cấu

hình

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 Ban quản lý cấu hình

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 10

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Tạo ra những thay đổi yêu cầu khi cần thiết theo kết qủa

đánh giá của mình

Thêm thực thể mới Người chịu trách nhiệm quản lý cấu hình

• Chỉ ra thực thể mới

• Phát hành một thực thể cấu hình làm nền tảng để tạo ra

thành phần mới thích hợp

Đồ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 Nhà sản xuất

đổi • 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 Người quản lý

đổi • Thông báo với những ai nhận phiên bản cấu hình trước

rằng đang có sẳn một phiên bản mới.

• Điều này làm cho nhà thầu khoán quyết định có muốn tạo

ra phiên bản mới hơn để sử dụng hay không

… …

Bảng 2-2 Mô tả hoạt động với mức độ hình thức cao

Trang 11

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.3.3 Cân nhắc lợi hạ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

Phí tổn

Phí tổn, phải được ước tính trước, phụ thuộc vào mức độ mong muốn. Chi phí

thường gồm:

• Chi phí về công cụ và hệ thống (phần mềm, phần cứng )

• Giờ làm của nhân viên bỏ ra và chi phí cho những trợ giúp tư vấn bên ngoài

như:

Về bổ sung: định nghĩa các quy trình và hệ thống, huấn luyện,..

Về những công việc thay đổi trong quản lý cấu hình

Tiết kiệm

Tiết kiệm bằng cách ngăn chặn những điều sau:

Trang 12

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• 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ế

Vấn đề Lợi ích của Quản lý cấu Giá trị kinh tế

hình

Cùng một lỗi được sửa– và Kịp thời nhận ra tất cả − Tiết kiệm (n-1)x (thời

những người khác nhau sẽ các biến ảnh hưởng và gian phân tích và sửa

sửa các biến khác nhau sửa lỗi tại một thời điểm lỗi của một thành phần

trong sản phẩm 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 Đăng ký tất cả các trạng − Tiết kiệm thời gian

những yêu cầu đã cũ thái và lịch sử của tất cả dành cho những cái sai

cá thực thể cấu hình cơ bản.

− Có sự thỏa mãn của

các nhân viên tham gia

Trang 13

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Những lỗi cũ xuất hiện lại Nhận biết được tất cả các − Tiết kiệm thời gian

khi một phiên bản mới được phiên bản của những tìm kiếm và sửa những

giao cho khách hàng thành phần cấu cũng như lỗi cũ

tất cả những thay đổi từ − Thỏa mãn được khách

phiên bản này sang phiên hàng vì chất lượng tốt

bản khác hơn

Nhà thiết kế và lập trình Một chức năng có thể − Tiết kiệm thời gian

viên giới thiệu những chức được theo dõi và chấp thực hiện (thiết kế,

năng không có trong yêu nhận trên hợp đồng/ hoặc code,.. ) cho những

cầu cũng bao gồm đặc tả yêu chức năng không

cầu, thay đổi yêu cầu mong muốn

Lỗi ở sản phẩm giao cho Biết được khách hàng − Tiết kiệm thời gian

khách hàng khó tìm thấy vì đang sử dụng version nào xác định phiên bản

ta không biết đã giao cho giao cho khách hàng

khách hàng phiên bản nào − 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 14

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Các phần mềm mới làm cho Thông tin về những lần − Tiết kiệm thời gian và

các khách hàng cũ. Vì ta thay đổi trong mỗi phiên công cụ để cập nhật

không biết rõ phiên bản cũ bản và biết được khách những thiết bị cũ

có hoạt động được cùng với hàng đã mua những − Làm giảm sự mất thời

công cụ mới hay không. Do phiên bản cũ nào. gian của khách hàng

đó, để an tòan, ta phải cập − Giảm thời gian cài đặt

nhật lại miễn phí các công

cụ cũ

Cùng một chức năng được Dễ dàng tìm lại những − Đánh giá việc phát

phát triển lại trong một số thực thể nào được dùng triển mới những thành

đề án. Dù ta biết, nhưng ta lại phần

lại không thể dùng lại vì − Tiết kiệm thời gian để

mất thời gian tìm kiếm và làm cho những thực

chỉnh sửa lại mã nguồn đó thể thích ứng với môi

đề cài đặt vào chức năng trường mới

của sản phẩm khác

Một nhân viên mới phải làm Đăng ký các mối liên hệ − Tiết kiệm thời gian

quen với sản phẩm bằng giữa mã nguồn và những dành cho những điều

cách đọc các tài liệu về sản tài liệu tương ứng, những sai cơ bản

phẩm. Tuy nhiên, tài liệu thay đổi, thời gian cập − Sự thỏa mãn của nhân

chưa được cập nhật, không nhật viên

ứ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 !

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 15

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.3.4 Những bẫy kết hợp với phạ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 ngoà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.).

Đị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 16

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4 Các vai trò trong quản lý cấu hì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 và quản lý cấu hì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 Quản lý cấu hình như là 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.

Yêu cầu

Quản lý cấu hình cần một kỹ thuật quản trị và một số đòi hỏi chuyên môn. Các

yêu cầu có thể là:

Quản lý cấu hình

• Một tầm nhìn tổng quát

Trang 17

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• 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 Quản lý cấu hình là 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 Các vai trò trong quản lý cấu hì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 quản lý cấu hì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 18

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• 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 19

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

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 quản lý

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 20

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

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 chịu trách nhiệm quản lý cấu hì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 21

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

trong công ty. Người này có thể có toàn quyền quản lý cấu hình trong công ty

nhưng có trách nhiệm hạn chế trong một tổ chức như sản xuất hay đề án.

Người chịu trách nhiệm quản lý cấu hình phải hợp tác với những người bên

trong và bên ngoài công ty. Người này chịu trách nhiệm trực tiếp tới người quản lý

đề án. Người này có mối quan hệ gần gũi với người chịu trách nhiệm quản lý quy

trình xem xét những quy trình tương ứng bên quản lý

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 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 22

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4.2.4 Kế họach quản lý cấu hì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 Các vai trò 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 Quản lý

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 23

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4.3.2 Người chịu trách nhiệm với tài sả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 chịu trách nhiệm trong quá trình vận hà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

Trang 24

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

vận hành có thể liên quan đến sản phẩm do chính công ty làm ra hoặc sản phẩm do

công ty mua từ bên ngoài. Việc vận hành có thể do nội bộ công ty dùng hoặc khách

hàng sử dụng dịch vụ.

Người chịu trách nhiệm về vận hành sẽ nhận một sản phẩm để vận hành vào

một thời điểm nào đó trong vòng đời. Cần chỉ rõ các khi nào vai trò này sẽ thực

hiện trách nhiệm và trách nhiệm của vai trò này là gì. Người này vận hành sản phẩm

hay những phiên bản mới của sản phẩm, có thể quay lại các phiên bản cũ khi phiên

bản mới .

Người này phải có quy ước làm việc: cách xử lý các phiên bản cũ của sản

phẩm khi phiên bản mới đưa vào vận hành. Phiên bản mới có thay thế hoàn toàn

phiên bản cũ hay chúng vận hành song song trong một khoảng thời gian cụ thể.

Trách nhiệm quản lý cấu hình

Người chịu trách nhiệm vận hành có thể chia sẻ công việc bằng nhiều cách

như với bộ phận phát triển hay bảo trì, hoặc có thể đảm nhận toàn bộ trách nhiệm về

bảo trì sản phẩm do đó liên quan đến quản lý cấu hình.

Trong một bào trường hợp, toàn bộ môi trường vận hành đặt dưới quản lý cấu

hình chung với sản phẩm vận hành. Khi đó, ta áp dụng các nguyên tắc quản lý cấu

hình bình thường dựa vào các loại thực thể cấu hình.

Trung bình hơn 50% sự kiện xảy ra trong vòng đời sản phẩm là do trong quá

trình vận hành. Đo đó, ta phải chỉ rõ trách nhiệm, các đăng ký các sự kiện và quy

trình thông qua hệ thống quản lý cấu hình.

2.4.3.4 Người chịu trách nhiệm qui trình quản lý

Người chịu trách nhiệm này thường làm việc trong một bộ phận xem xét trên

nhiều đồ án của công ty như Ban đề ra các phương pháp và công cụ hoặc ban quản

lý chất lượng. Người này đảm bảo quy trình dùng trong đề án và các bộ phận khác

đáp ứng yêu cầu của công ty và thoả mãn một cách hiệu qủa. Những phần thuộc

những quy trình này là những quy trình quản lý cấu hình. Người này cũng để các

quy trình của công ty (sản phẩm công việc của họ) dưới quản lý cấu hình

Trang 25

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Người chịu trách nhiệm về quy trình quản lý phải liên lạc với nhiều người có

một vài ý kiến khác về quy trình yêu cầu. Do đó, người này phải có kiến thức vững

chắc về:

• Phong tục, giá trị, mục tiêu của công ty

• Phát triển phần mềm nói chung và đặc biệt trong mối liên hệ với công ty

• Các nguyên lý của quản lý cấu hình cụng như cách thực hiện quản lý cấu

hình trong công ty.

Các hoạt động của vai trò này bao gồm:

• Biên soạn một mô tả quy trình để quản lý cấu hình

• Biên soạn hướng dẫn tuỳ biến các mô tả quy trình để tuỳ vào nhu cầu của

các đề án

• Xem xét việc tuỳ biến quy trình thực hiện quản lý cấu hình trong công ty.

• Thu thập và phân tích các phép đo theo kế hoạch đo

• Điều chỉnh định nghĩa quy trình dựa vào phân tích các phép đo

• Huấn luyện các nhân viên khác trong quản lý cấu hình.

2.4.3.5 Người chịu trách nhiệm về môi trường và công cụ

Người chịu trách nhiệm về môi trường và công cụ đảm bảo các công cụ yêu

cầu phải có sẳn và làm việc tốt. Người này cũng thực hiện hỗ trợ việc sử dụng công

cụ. Người này cũng có thể có trách nhiệm quản lý công cụ cấu hình của công ty và

các sản phẩm liên quan như bản hướng dẫn sử dụng, các bản script cài đặt, các

script trao đổi dữ liệu.

Người này phải có sự hứng thú quan tâm đến các công nghệ mới, đặc biệt liên

quan đến quản lý cấu hình.

Người này phải có kiến thức vững chắc về quản lý cấu hình nói chung và quản

lý cấu hình của công ty. Các hoạt động của người này trong mối quan hệ với công

cụ quản lý cấu hình có sẳn bao gồm:

• Cài đặt các công cụ

Trang 26

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Tạo ra các công cụ hỗ trợ cần thiết hoặc sự liên hệ giữa các công cụ (như

các scripts)

• Bảo trì các công cụ cài đặt, bao gồm viêc liên lạc với các nhà cung cấp.

• Hỗ trợ cho người dùng các công cụ quản lý cấu hình

• Huấn luyện nhân viên sử dụng công cụ

2.4.3.6 Ban hỗ trợ

Ban hỗ trợ hướng dẫn và giúp đỡ khách hàng. Thực hiện liên kết giữa những

người sử dụng và người chịu trách nhiệm bảo trì hệ thống bằng cách đăng ký và khả

năng theo vết các sự kiện thích hợp. Việc hỗ trợ cá nhân phải có kiến thức dùng các

công cụ quản lý cấu hình để đăng ký các sự kiện và rút thông tin từ siêu dữ liệu.

Phải biết những thông tin có sẳn về những thực thể quản lý cấu hình và các sự kiện

đăng ký và cách lấy ra nhanh nhất.

Nhân viên của phòng hỗ trợ dựa vào thông tin của quản lý cấu hình để giải

quyết các công việc hỗ trợ. Những hoạt động thường bao gồm:

• Đăng ký các sự kiện thích hợp với các thông tin yêu cầu đúng

• Theo dõi các sự kiện đăng ký để hỗ trợ yêu cầu xử lý.

• Thu thập thông tin từ hệ thống quản lý cấu hình khi trả lời các truy vấn và

đăng ký các sự kiện. Điều này có thể:

− Thông tin đăng ký trên các sự kiện giống nhau

− Định danh các thực thể cấu hình để sử dụng

− Giải pháp tạm thời cho vấn đề

− Thay đổi lịch sử của thực thể cấu hình ( Một hệ thống hoặc một phần của hệ

thống)

− Thông tin dựa trên nội dung của deliveries

− Việc tiến hành của một sự kiện đăng ký

Trang 27

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4.4 Các vai trò liên quan đến đề án

Các vai trò mô tả ở đây liên quan đến việc tiến hành thực hiện đề án và có

quan hệ với một đề án tại một thời điểm. Tập trung vào mối quan hệ của chúng với

quản lý cấu hình

Không phải vai trò nào cũng cần thiết trong tất cả các đề án. Lượng công việc

tuỳ thuộc vào mức độ hình thức.

2.4.4.1 Người phân tích

Các nhà phân tích thực hiện các hoạt động sớm trong chu kỳ sống của sản

phẩm, như đặc tả các yêu cầu cho phần mềm, tài liệu khác. Nhà phân tích sẽ lưu giữ

các tài liệu này trong suốt chu kỳ sản phẩm, tạo ra phiên bản mới nếu thay đổi yêu

cầu. Nhà phân tích dùng hệ thống quản lý cấu hình để phân tích hoạt động để mở

rộng việc thực hiện quản lý cấu hình.

Nhà phân tích phải có quản lý cấu hình trong đầu khi làm việc. Nó bao gồm

các yêu cầu như các biến số, mà có thể xử lý một cách hợp lý với hệ thống xử lý

thích hợp với hệ thống quản lý cấu hình hiện tại. Việc phân tích quản lý cấu hình

giúp thực hiện quản lý cấu hình bằng:

• Chỉ ra các thực thể thích hợp

• Đặt các thực thể thích hợp tuỳ vào nơi lưu trữ tuỳ vào thực thể đó được

chấp nhận như thế nào.

• Tạo ra việc đăng ký thích hợp cho các thực thể được dùng nhờ vào phân

tích (như hợp đồng hoặc các đặc tả yêu cầu sử dụng)

Phân tích cũng có thể liên quan đến ban quản lý cấu hình trong việc đánh giá

các sự kiện đăng ký trong các hoạt động phát triển sau.

Lợi ích

Lợi ích của việc đặc sản phẩm dưới sự quản lý cấu hình có thể mang lại lợi

nhuận, người phân tích có lợi từ quản lý cấu hình dựa vào:

• Rút trích ra các thực thể cấu hình liên quan dựa trên các đối tượng phân

tích, như các hợp đồng hoặc các đặc tả yêu cầu người dùng

Trang 28

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Lấy thông tin về trạng thái và lịch sử của các thực thể này.

• Theo dõi kết qủa đối với các thực thể, đảm bảo việc phân tích bao hết các

yêu cầu.

2.4.4.2 Người thiết kế

Nhà thiết kế tạo ra kiến trúc, các thiết kế chi tiết và lưu lại các tài liệu này

trong suốt vòng đời của sản phẩm, tạo ra các phiên bản mới theo thay đổi yêu cầu.

Tất cả các hoạt động quản lý cấu hình phải được thực hiện cho các hoạt động thiết

kế mà người này chịu trách nhiệm.

Nhà thiết kế luôn phải có trong đầu khi nào công việc được thực hiện xong.

Các nhà thiết kế đóng góp vào việc thực hiện quản lý cấu hình bằng:

• Chỉ ra các thực thể cấu hình liên quan (các tài liệu thiết kế)

• Đặt các thực thể cấu hình thích hợp trong nơi lưu trữ sau khi được chấp

nhận

• Tạo ra các sự kiện đăng ký thích hợp cho các thực thể được dùng liên hệ

với công việc thiết kế như đặc tả yêu cầu người dùng và đặc tả yêu cầu

phần mềm.

Các nhà thiết kế có thể cũng liên quan đến ban quản lý cấu hình trong việc

đánh giá các sự kiện đăng ký về sau trong các hoạt động phát triển.

Lợi ích

Thuận lợi của việc đặc các sản phẩm của họ dưới quản lý cấu hình, các nhà

thiết kế có thể hưởng lợi từ quản lý cấu hình bằng cách:

• Rút ra các thực thể cấu hình liên quan để tạo ra các thực thể, như lấy ra đặc

tả yêu cầu phần mềm.

• Lấy thông tin về trạn thái và lịch sử của những thực thể này

• Lấu kết qủa phân tích trên những thực thể này để đảm bảo thiết kế đáp ứng

các yêu cầu

Trang 29

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4.4.3 Lập trình viên

Lập trình viên thực hiện tất cả các hoạt động lập trình, tạo ra mã nguồn và

những đối tượng liên quan như hệ thống dữ liệu và xây dựng các file script. Chúng

thực hiện bảo trì các đối tượng lập trình trong vòng đời của sản phẩm, tạ ra version

mới khi có thay đổi yêu cầu. Họ chịu trách nhiệm cho việc kiểm thử chính đoạn mã

của mình như thực hiện các module test, và cũng thực hiện các kiểm thử tích hợp.

Tất cả các hoạt động quản lý cấu hình phải được thực hiện để lập trình và các

hoạt động khác mà người chịu trách nhiệm như kiểm thử. Những người lập trình

góp vào việc thực hiện quản lý cấu hình bằng cách:

• Chỉ ra các thực thể cấu hình thích hợp (mã ngưồn và các file đối tượng)

• Đặt các thực thể cấu hình trong bộ nhớ sau khi được chấp nhận

• Tạo ra các sự kiện đăng ký thích hợp cho các thực thể được dùng liên hệ

với lập trình như đặc tả các yêu cầu hoặc thết kế.

Các nhà lập trình cũng có thể liên quan đến ban quản lý cấu hình trong việc

đánh giá các sự kiện đăng ký.

Lợi ích

• Rút ra các thực thể cấu hình để dựa vào có thể tạo ra các đối tượng lập

trình, như đặc tả yêu cầu phần mềm và thiết kế

• Lấy thông tin trên trạng thái và lịch sử của các thực thể này.

• Theo dõi kết qủa phân tích trên các thực thể để đảm bảo mã nguồn và các

đối tượng liên quan đúng với thiết kế và các yêu cầu của phần mềm

2.4.4.4 Người tích hợp

Những người tích hợp tích hợp mã nguồn vào trong các hệ thống ngày lớn để

tạo thành toàn hệ thống.

Việc định danh chính xác nội dung bên trong của sản phẩm thì cần cho việc

kiểm thử và các hoạt động đăng ký. Người tích hợp nên dùng hệ thống quản lý cấu

hình trong các hoạt động tích hợp.

Trang 30

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Những người tích hợp đóng vai trò trung tâm liên hệ với quản lý cấu hình.

Người này dùng quản lý cấu hình vào:

• Chỉ ra các thực thể cấu hình tương ứng (xâu dựng các script, các deliveries

vào những hệ thống lớn)

• Đặt các thực thể thích hợp vào nơi lưu trữ sau khi được chấp nhận.

• Tạo ra các sự kiện đăng ký thích hợp cho thực thể được dùng có quan hệ

với tích hợp như mã nguồn.

Những người tích hợp có một tầm nhìn về hệ thống và thông tin bao gồm trên

thực thể cấu hình. Họ cũng góp phần vào kiểm tra các thực thể cấu hình theo cách

nhìn tổng quan của mình, đảm bảo các thực thể cần thiết cho một phiên bản giao thì

tồn tại tương ứng.

Lợi ích

Lợi ích của việc đặt quản sản phẩm vào quản lý cấu hình, các nhà tich hợp có

lợi từ quản lý cấu hình bằng cách:

• Rút trích các thực thể cấu hình liên quan như là một tích hợp cơ sở (như

thiết kế kiến trúc, kế hoạch phát triển, và kế hoạch kiểm thử)

• Rút trích các thực thể cấu hình từ đó tạo ra các thực thể riêng của chúng.

• Lấy thông tin về trạng thái và lịch sử của những thực thể này.

2.4.4.5 Nhà quản lý đề án

Nhà quản lý đề án có tất cả các trách nhiệm lập kế hoạch quản lý cấu hình theo

yêu cầu của đề án. Người này chịu trách nhiệm lập kế hoạch quản lý cấu hình theo

yêu cầu của đề án và xem xét việc thực hiện. Nó bao gồm cái mà nhân viên tạo ra

và cái mà nhà quản lý đề án tạo ra (kế hoạch đề án).

Để có thể định nghĩa phạm vi và nhiệm vụ của quản lý cấu hình, nhà quản lý

đề án phải hiểu yêu cầu và có thể thực hiện chúng. Nhà quản lý phải hiểu vai trò của

quản lý cấu hình và truyền đạt lại cho các nhân viên cấp dưới. Thuận lợi nếu quản

Trang 31

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

lý đề án có kiến thức tốt về quản lý cấu hình nói chung không chỉ liên quan đến đề

án thực hiện.

Quản lý cấu hình là một phần những hoạt động bao gồm trong lập kế hoạch và

ngân sách cho đề án. Quản lý cấu hình phải đảm bảo những tài nguyên cần thiết cho

con người và ngân sách cho đề án. Nhà quản lý phải đảm bảo các tài nguyên cho

con người và cơ sở hạ tầng bao gồm trong kế hoạch và thật sự cung cấp cho những

người liên quan. Các hoạt động liên quan đến quản lý cấu hình có thể là:

• Tạo và cập nhật kế hoạch quản lý cấu hình

• Chỉ ra các vai trò quản lý cấu hình cần thiết trong đề án

• Gán trách nhiệm về các hoạt động quản lý cấu hình tương ứng với các vai

trò chỉ ra.

• Chỉ ra các tài nguyên để quản lý cấu hình

• Theo dõi các hoạt động quản lý cấu hình đã được lập kế hoạch

Các hoạt động này quan trọng trong việc thực hiện quản lý cấu hình và thực

hiện đúng trong đề án và trong công ty. Sự năng động của quản lý đề án và thấy

được lợi ích của quản lý cấu hình có thể là nguồn động lực cho nhân viên thực hiện

quản lý cấu hình.

Lợi ích

Nhà quản lý đề án có thể dùng

• Báo cáo trạng thái của hệ thống quản lý cấu hình để xem xét các thực thể

cấu hình

• Thông tin về các sự kiện đăng ký và sự tiến triển của chúng

• Các kết qủa đo từ hệ thống quản lý cấu hình, để xem xét về quản lý cấu

hình và nhựng quy trình khác

2.4.4.6 Người chịu trách nhiệm về chất lượng

Người này đảm bảo các hoạt động chất lượng đáp ứng tất cả các yêu cầu cho

sản phẩm. Người này đảm bảo các hoạt động quản lý chất lượng được thực hiện

như mong muốn bằng cách theo dõi các báo cáo chất lượng và quản lý cấu hình ,

Trang 32

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

thực hiện thanh ra các yêu cầu, kiểm tra mã. Người này đảm bảo các quy trình khác

trong đề án được theo dõi như mong muốn.

Để kiểm tra quản lý cấu hình, người chịu trách nhiệm phải có kiến thức tốt về

quản lý cấu hình nói chung và cho đề án nói riêng. Người này phải có kiến thức tốt

về độ đo quản lý cấu hình có thể tạo ra và cách dùng. Các hoạt động liên quan đến

quản lý cấu hình:

• Thiết lập yêu cầu liên quan đến các hoạt động quản lý cấu hình và kết qủa.

• Theo dõi chất lượng của các hoạt động quản lý cấu hình đã được lập kế

hoạch; định danh, lưu trữ, và sử dụng các thực thể cấu hình; xử lý các thay

đổi yêu cầu

• Tạo ra các sự kiện đăng ký đối với các thực thể liên quan, nếu các sự kiện

được theo dõi.

• Báo cáo và tóm tắt kết qủa chất lượng đạt được.

Các hoạt động quản lý chất lượng và các hoạt động quản lý cấu hình đan xen

vào nhau.

2.4.4.7 Người chịu trách nhiệm hợp đồng với khách hàng

Người này chịu trách nhiệm khách hàng được thoã mản theo như hợp đồng.

Thường quản lý đề án thực hiện nhiệm vụ này, còn các đề án lớn thì có một người

riêng lo về nhiệm vụ này.

Người này phải hiểu yêu cầu của khách hàng về quản lý cấu hình và đảm bảo

chúng được đáp ứng. Làm rõ đường biên quản lý cấu hình của đề án và của khách

hàng và cách chúng tương tác với nhau. Nhiệm vụ của công việc này xem xét cách

các sự kiện đăng ký được xử lý trong quy trình phát triển hoặc cách chuyển từ đề án

sang quản lý cấu hình của khách hàng tạo lúc giao.

Để có thể hợp tác với khách hàng về quản lý cấu hình, người này phải có kiến

thức cơ bản về quản lý cấu hình. Các loại hoạt động phụ thuộc vào cách hợp tác với

khách hàng (chặt chẽ hay gần gũi). Dựa trên hợp đồng, các hoạt động thường bao

gồm:

Trang 33

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Tạo ra tài liệu đáp ứng các yêu cầu quản lý cấu hình

• Nhận và thực hiện quản lý chất lượng trên các deliveries cho khách hàng

như đặc tả yêu cầu người dùng, và có thể thực hiện quản lý cấu hình nội bộ

bên trong

• Chuyển các sự kiện đăng ký cho khách hàng.

• Nhận các sự kiện đăng ký từ khách hàng, như việc xem xét tài liệu hoặc

xem các phiên bản demo

2.4.4.8 Người chịu trách nhiệm cho các hợp đồng phụ

Người chịu trách nhiệm cho các hợp đồng phụ đảm bào sự hợp tác với các

người thầu phụ.. Với mỗi hợp đồng phụ, một hợp đồng yêu cầu cần chỉ rõ các thuật

ngữ và bản phát hành cuối. Người chịu trách nhiệm đảm bảo các hoạt động quản lý

cấu hình phụ đáp ứng các yêu cầu.

Ranh giới giữa quản lý cấu hình trong đề án và của hợp đồng phụ phải rõ ràng,

cũng như mối quan hệ xen giữa chúng. Các hợp đồng phụ có thể đặt các thực thể

của mình vào quản lý cấu hình độc lập với phần còn lại của sản phẩm, nhưng tất cả

chúng phải được chuyển vào hệ thống quản lý cấu hình của đề án trong mối liên hệ

với delivery.

Để có thể hợp tác với các hợp đồng phụ về quản lý cấu hình, người chịu trách

nhiệm các hợp đồng phụ phải có kiến thức tốt về các nguyên tắc chung của quản lý

cấu hình và áp dụng vào công ty và đề án. Người giữ vai trò này phải hiểu các

phương pháp làm việc của hợp đồng phụ. Thiết lập các yêu cầu quy ước về quản lý

cấu hình trong các hợp đồng phụ và thực hiện.

Dựa vào hợp đồng, các hoạt động thường bao gồm:

• Định nghĩa những yêu cầu trong hệ thống quản lý cấu hình của các hợp

đồng phụ

• Lưu trữ mối liên hệ giữa hợp đồng phụ và đề án

• Theo dõi các hợp đồng phụ để đảm bảo các yêu cầu quản lý cấu hình được

thoả mãn

Trang 34

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Nhận và thực hiện quản lý chất lượng trên các sản phẩm chuyển giao phụ

và qua đó quản lý cấu hình bên trong các sản phẩn đó.

• Gửi đi các sự kiện đăng ký và những thay đổi yêu cầu có thể tới hợp động

phụ mà những thành phần cấu hình mà hợp đồng phụ chịu trách nhiệm

• Nhận đăng ký các sự kiện từ hợp đồng phụ

2.4.5 Các vai trò bên ngoài

Quản lý cấu hình thì không chỉ giới hạn ở công ty phát triển và bảo trì sản

phẩm. Giả sử công ty là một nhà thầu khoán. Cả khách hàng và hợp đồng con phải

góp phần trong hợp đồng phát triển và bảo trì phần mềm. Hình dưới chỉ ra mối quan

hệ giữa các khái niệm về khách hàng, thầu khoán, người thực hiện hợp đồng phụ và

cách mà các sản phẩm thường được giao

Hình 2-4 Khách hàng, người ký hợp đồng, các hợp đồng phụ

Tuy nhiên, một vài mối quan hệ với quản lý cấu hình thường xảy ra và theo 2

hướng. Do đó, tất cả các bên phải chỉ rõ cách giao tiếp để trao đổi các deliveries và

thông tin quản lý cấu hình.

2.4.5.1 Khách hàng

Các hoạt động của khách hàng gồm

• Tham gia vào một hay nhiều ban quản lý cấu hình

• Tạo ra các sự kiện đăng ký

• Phê duyệt các thực thể tạo ra

Trang 35

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.4.5.2 Nhà thầu phụ

Các hoạt động quản lý cấu hình của hợp đồng phụ phụ thuộc vào việc thoả

thuận trong hợp đồng, nhưng nhìn chung nó bao gồm toàn bộ các hoạt động của

quản lý cấu hình.

2.5 Dữ liệu cho quản lý cấu hình

2.5.1 Cái gì được đưa vào quản lý cấu hình

Nhiều đối tượng được tạo ra hoặc mua trong quá trình tạo ra phần mềm. Nói

chung, mọi thứ điều đặt trong quản lý cấu hình. Một đối tượng đặt trong quản lý cấu

hình gọi là một thực thể cấu hình (configuration item). Một thực thể cấu hình có thể

là một phần trong phiên bản đang phát triển, phiên bản giao, sản phẩm. Chúng được

định danh, tạo ra, lưu trữ, sử dụng và thay đổi.

Mỗi thực thể có độ phức tạp khác nhau. Một thực thể cấu hình có thể là một

thực thể riêng biệt hay là một tập hợp những thực thể khác, còn gọi là deliveries mà

có thể đặt vào quản lý cấu hình với quyền riêng.

2.5.1.1 Các đối tượng vật lý hay điện tử

Không chỉ có mã nguồn được đặt dưới sự quản lý cấu hình, các đối tượng cần

để hỗ trợ phát triển, bảo trì phần mềm cũng được quản lý.

Phân cấp thực thể cấu hình

Hình 2-5 Sơ đồ phân cấp các thực thể cấu hình

Những đối tượng vật lý

Những tính chất của một đối tượng vật lý trong quản lý cấu hình là:

• Số lượng sao chép bị giới hạn – thường chỉ là một

Trang 36

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Khi bản sao chép của đối tượng được đem ra bên ngoài, số lượng các bản

sao chép giảm xuống

• Nó không lưu trên một máy tính mà phải lưu ở một nơi vật lý

• Không thể tạo ra các siêu dữ liệu cho các đối tượng này.

• Trong các công cụ quản lý cấu hình cũ, không thể xử lý các đối tượng vật lý

mà không phải tạo một đối tượng giả ở bên điện tử

• Chỉ những hệ thống xử lý hiện đại mới có thể trích ra đối tượng vật lý từ

kho chứa dựa trên siêu dữ liệu

Ví dụ:

• Giấy phát thảo ý tưởng ban đầu

• Các máy trạm như một phần của hệ thống

• Các máy trạm dùng để phát triển

• Dây cáp

• Hộp tích hợp các phần mềm và phần cứng

• Các mạch

Những đối tượng điện tử

Các tính chất :

• Không giới hạn số lượng sao chép, dễ tạo ra các sao chép

• Khi đem ra một bản sao chép thì không làm giảm số lượng sao chép

• Các bản sao chép được tạo ra, rút trích, phân phối mà không cấn thông báo

cho một ai.

• Các bản sao chép có thể ở hình thức điện tử hoặc vật lý

• Nó được lưu trữ điện tử

• Siêu dữ liệu của đối tượng có thể gồm chính đối tượng và trong máy tình

(như một phần của hệ điều hành và công cụ )

• Siêu dữ liệu là con trỏ trực tiếp tới đối tượng và dùng để rút trích đối tượng

từ nơi lưu trữ

Trang 37

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Ví dụ: các tài liệu yêu cầu viết bằng Word, một module phần mềm viết bằng

C, một hệ thống cơ sở dữ liệu (middleware) và hệ điều hành.

2.5.1.2 Các loại đối tượng theo cách nhìn sản phẩm

Sản phẩm được kết hợp từ nhiều loại sản phẩm con như phần mềm, phần

cứng, mạng, dữ liệu và dịch vụ. Với mỗi loại sản phẩm phụ, mỗi đối tượng riêng rẽ

có thể đặt trong quản lý cấu hình. Một đối tượng của sản phẩm phụ có thể là thành

tố phụ, thành tố và sản phẩm.

Phần dưới chỉ ra một vài ví dụ các đối tượng đặt dưới sự quản lý cấu hình của

một đề án thật sự

Phần mềm

Những đối tượng có quan hệ đến phần mềm, những loại đặc dưới sự quản lý

cấu hình có thể là : các header files, include files, files mã nguồn, hệ thống thư viện,

file đối tượng và file thực thi. Các file dẫn xuất (như file thực thi), có thể đặt vào hệ

thống quản lý cấu hình cùng với / thay vì các đối tượng tạo ra nó.

Phần cứng

Việc lưu lại các mội trường khác nhau là cần thiết như môi trường phát triển,

môi trường kiểm thử, môi trường tạo sản phẩm…

Phần cứng là yêu cầu về phần cứng của sản phẩm. Có thể là cab, máy (máy

chủ, máy cá nhân, máy trạm), bộ nhớ (ROM/EPROM/EEROM), thiết bị lập trình

logic - programmable logical device (PLD), hoặc các thiết bị ngoại vi khác (đầu ghi

CD, máy in, máy quét,..).

Mạng

Sản phẩm phụ mạng là sản phẩm phức tạp, nó có thể ngoải kiểm soát của sản

phẩm như Internet. Đối tượng đặt dưới sự quản lý cấu hình của sản phẩm con mạng

là tường lửa (cả tường lửa phần mềm và phần cứng), mạng vật lý (LAN/WAN),

thao thức protocol, servers, switches.. Các đối tượng này có thể là điện tử hoặc vật

lý.

Trang 38

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Dữ liệu

Dữ liệu chuyển đi của sản phẩm có thể là tham số của hệ thống dữ liệu như hệ

thống tiền tệ. Dữ liệu chỉ được chuyển qua file (flat file hay file cơ sở dữ liệu) – dữ

liệu là đối tượng điện tử.

Dịch vụ

Các dịch vụ thì không thể sờ lấy được nên không thể đặt vào quản lý cấu hình.

Tuy nhiên, các đối tượng khác hữu hình có thể cho ta biết được các dịch vụ qua các

mô tả về quy trình, sự thoả thuận, hợp đồng, tài liệu giảng dạy. Các đối tượng này

có thể là đối tượng điện tử hay vật lý.

Các công cụ

Các công cụ dùng trong sản xuất ra các đối tượng kể trên có thể đặt dưới quản

lý cấu hình. Các công cụ có thể là các công cụ vẽ, bộ soạn thảo, trình biên dịch,

công cụ cơ sở dữ liệu..

2.5.1.3 Các loại đối tượng theo cách nhìn đề án

Một đền án gồm nhiều hoạt động trong vòng đời (vd: chuẩn bị, đặc tả yêu cầu,

thiết kế, sản xuất, tích hợp, kiểm thử, vận hành và bảo trì). Trong toàn bộ chu kỳ

sống của sản phẩm, cần có các chức năng hỗ trợ như quản lý đề án, quản lý chất

lượng, quản lý cấu hình. Mỗi một hoạt động trong chu kỳ sống, mỗi một chức năng

hỗ trợ sẽ tạo ra các loại đối tượng, và chúng sẽ được đặt dưới sự quản lý cấu hình

Các phần ở dưới sẽ trình bày các ví dụ về đối tượng đặt dưới quản lý cấu hình

trong các hoạt động trong chu kỳ sống và các chức năng hỗ trợ. Các đối tượng này

không nhất thiết phải giao cho khách hàng

Các hoạt động trong chu kỳ sống

Các tài liệu của đề án phát sinh từ các hoạt động trong chu kỳ sống.

Ví dụ:

• Chuẩn bị (hợp đồng, thoả thuận công việc, yêu cầu người dùng)

• Đặc tả yêu cầu (yêu cầu phần mềm, yêu cầu phụ khác, các biểu mẫu, kịch

bản)

Trang 39

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Thiết kế (đặc tả thiết kế kiến trúc)

• Sản xuất, sự tích hợp, kiểm thử (các thiết bị, lỗi, dữ liệu test, quy trình test,

các báo cáo kiểm thử)

• Vận hành và bảo trì (các quy trình tái sản xuất, các quy trình cài đặt, quy

trình thực hiện)

Các chức năng hỗ trợ

Các đối tượng, các chức năng hỗ trợ trong quá trình thực hiện có thể là:

• Quản lý đề án (kế hoạch đề án, thời gian biểu, các báo cáo)

• Quản lý chất lượng (kế hoạch, các báo cáo về chất lượng)

• Quản lý cấu hình (kế hoạch, yêu cầu, các sự kiện đăng ký, thay dổi yêu cầu,

các báo cáo trạn thái)

Công cụ

Các công cụ dùng trong sản xuất ra các đối tượng

2.5.1.4 Các loại đối tượng trong tổ chức

Các công ty đều có các đối tượng phân cấp mà quản lý cấu hình phải xem xét

như các tài liệu về quản trị, sản phẩm tài sản cuả công ty, cấu trúc hạ tầng, hoặc một

hệ thống chất lượng.

Các tài liệu quản trị

Các tài liệu quản trị được kiểm soát cấu hình như các thư từ trao đổi (thư,

email, fax,..) các mô hình ban đầu (các prototypes, slides trình bày.. ), các đơn đặt

hàng (hợp đồng) , các kế hoạch (hướng phát triển cuả công ty, lập chiến lược, kế

hoạch tổ chức, các kế hoạch cá nhân). Các tài liệu trên có thể là cuả một đề án cụ

thể hoặc cuả một bộ phận quản lý, hoặc của toàn công ty.

Những đối tượng này thường không đặt dưới sự quản lý cấu hình. Tuy nhiên,

ta cũng cần xem xét việc quản lý nó, ít nhất là đối với những đối tượng quan trọng.

Các đối tượng nào được coi là quan trọng thì tuỳ thuộc vào quyết định của công ty.

Các sản phẩm tài sản của công ty

Trang 40

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Các sản phẩm tài sản của công ty thường là các thành tố sử dụng lại. Ta phải

quản lý cấu hình chặt chẽ đối với các đối tượng này.

Cơ sở hạ tầng

Cơ sở hạ tầng trong công ty là môi trường các nhân viên làm việc. Đối tượng

quản lý cấu hình bao gồm các công cụ phát triển (trình biên dịch, linkers), phần

cứng (máy tính, máy in, máy trạm), hệ điều hành, mạng, các công cụ.

Hệ thống chất lượng

Hệ thống chất lượng nói lên các tài liệu và mô tả quy trình mà công ty đang

thực hiện. Nó bao gồm các định nghĩa quy trình, các mẫu, các tiêu chuẩn.

2.5.1.5 Các sản phẩm phân phối trong quản lý cấu hình

Trong sản phẩm giao là cấu trúc phân cấp của nhiều thực thể cấu hình. Nó có

thể được xây dựng từ những sản phẩm giao khác theo cấu trúc nhánh.

Nhu cầu xử lý một nhóm các thực thể xuất hiện khi cần xử lý một bộ các thực

thể. Ví dụ như lấy ra một phần hoặc toàn bộ hệ thống, lấy ra các phiên bản để test,

giao cho khách hàng.

Ví dụ

Một đặt tả yêu cầu coi như một sản phẩm phải bàn giao. Nó tạo thành từ các

yêu cầu riêng rẽ và mỗi yêu cầu riêng cũng đặt dưới sự quản lý cấu hình.

Hình 2-6 Đặc tả yêu cầu của một delivery

Trang 41

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Hình 2-7 Mối quan hệ về phần cứng của delivery

Mối quan hệ trong các đề án

Các mối quan hệ giữa các thực thể cấu hình trong các deliveries thì hoàn toàn

do mục đích phát hành để sử dụng và quản lý cấu hình. Những mối quan hệ này

không nên lẫn lộn với những mối quan hệ thiết lập qua lập kế hoạch, thiết kế.. Hai

loại quan hệ này có thể có nhiều thể hiện giống nhau, và cách danh sách quan hệ có

thể có ích cho quản lý cấu hình và những việc khác.

Điều này nên làm vì đối với một hệ thống quản lý cấu hình lớn, người chịu

trách nhiệm quản lý đề án hoặc nhà phát triển có nhiệm vụ phải chỉ ra các mối quan

hệ lập kế hoạch hoặc phân tích, không phải trách nhiệm của quản lý cấu hình.

2.5.1.6 Lập kế họach phân phối theo các mốc thời gian

Mô hình phát triển

Mô hình phát triển được chia nhỏ từng công việc để phát triển, sản xuất, bảo

trì. Ví dụ như mô hình thác nước và mô hình phát triển lặp – các công việc ngắn

hơn, nhưng chúng được lặp lại trong chu kỳ sống của đề án.

Với bất cứ quy trình phát triển nào của đề án, mỗi hoạt động nên kết thúc với

một mốc cụ thể và phát sinh một bản delivery cụ thể: a milestone delivery.

Các mốc phân chia

Số lượng, tên, nội dung các mốc phân chia phụ thuộc vào từng đề án và mô

hình phát triển.

Ví dụ các mốc phân chia trong đề án theo quy trình thác nước như sau:

• Kết thúc chuẩn bị

• Kết thúc đặc tả yêu cầu

Trang 42

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Kết thúc đặc tả yêu cầu phần mềm

• Kết thúc thiết kế kiến trúc

• Kết thúc thiết kế chi tiết

• Kết thúc lập trình và kiểm thử trên các module

• Kết thúc kiểm thử tích hợp

• Kết thúc kiểm thử hệ thống

• Kết thúc kiểm thử

• Bản giao cuối

Các delivery này sẽ ngày một tăng khi càng phát triển đề án.

Hình dưới chỉ ra ví dụ milestone deliveries và nội dung của chúng suốt giai

đoạn phát triển cùng với các số phiên bản tương ứng.

Milestone

Bao gồm Kết thúc Kết thúc Kết thúc Kết thúc Kết thúc Chấp nhận

các thực thể yêu cầu thiết kế thiết kế kiểm thử kiểm thử cuối cùng

cấu hình kiến trúc chi tiết các system kết qủa

module test test của hệ

thống

Lập kế 1.0 2.0 3.0 4.0 4.1 4.1

hoạch

Kế hoạch 1.0 2.0 3.0 4.0 4.0 4.0

quản lý cấu

hình

kế Lập 1.0 2.0 3.0 4.5 5.2 6.3

hoạch test

và đặc tả

test

Đặc tả yêu 1.0 1.2 1.3 1.4 1.6 1.6

Trang 43

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

cầu

Thiết kế — 1.0 1.2 1.3 1.3 1.3

kiến trúc

Thiết kế chi — 1.0 1.1 1.2 1.3 —

tiết

User — 1.0 1.1 1.1 — —

manual

Tài liệu sử

dụng

Phân hệ 1 — — — 1.0 1.1 1.2

Phân hệ 2 — — — 1.0 1.1 1.2

Trình biên — — — 4.3 4.3 4.3

dịch

Linker — — — 7.2.5 7.2.5 7.2.6

Hệ thống — — — — 1.0 1.1

hoàn chỉnh

Ghi chú — — — — — 1.0

phát hành

Dấu gạch ngang chỉ ra sự thực cấu hình đó không nằm trong delivery

2.5.2 Những điều cần biết về một thành phần cấu hình

Mỗi thực thể cấu hình có một lượng thông tin nhất định mà ta phải theo dõi

trong suốt dòng đời của thành phần.

2.5.2.1 Tổng quan về siêu dữ liệu của thực thể cấu hình

Các yếu tố dữ liệu

Hình 2-8 đưa ra những yếu tố dữ liệu nào hình thành nên một phần của siêu dữ

liệu cho một thành phần quản lý cấu hình – đó là dữ liệu mô tả thành phần cấu hình.

Các yếu tố dữ liệu có thể được chia vào những nhóm chung sau:

Trang 44

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

• Cánh định danh duy nhất

Mối quan hệ thuộc về

• Tất cả dữ liệu chỉ liên quan đến thực thể cấu hình đó, như chỉ ra bên trong

hộp “Thực thể cấu hình”.

• Chịu trách nhiệm

Những mối quan hệ “tạo ra bởi”, “chịu trách nhiệm bởi” và “chấp nhận bởi”

• Mối quan hệ đối với các thành phần cấu hình khác

• Những mối quan hệ “theo dõi ”, “tạo ra với”, “bắt nguồn từ”, và “bao gồm”

• Sự phân phối

• Những mối quan hệ “phân phối cho” và “đã được phân phối cho”

Hình 2-8 Tổng quan về siêu dữ liệu

Metadatabase Medium

Việc đăng ký siêu dữ liệu có thể thực hiện theo nhiều cách khác nhau. Siêu dữ

liệu cho quản lý cấu hình cũng mở rộng bằng nhiều cách. Trước đây, đa số được

thực hiện đăng ký bằng giấy. Có nghĩa là sẽ điền vào một đơn, ghi nhận lại, cập

nhật đối với mỗi thành phần cấu hình. Ngày nay, nó không còn phổ biến khi cơ sở

dữ liệu được dùng một rãi trong việc đăng ký

Phần của việc đăng ký phải nằm luôn trong chính thành phần cấu hình. Ví dụ:

tên tác giả thì thường được viết ở mặt trước của tài liệu hoặc trên phần đầu của file

Trang 45

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

mã nguồn. Phần đăng ký sẽ diễn ra ở trong công cụ dùng để lưu trữ thành phần cấu

hình. Nhưng công cụ không phải luôn có thể đăng ký tất cả các siêu dữ liệu.

Phần quan trọng nhất là xem xét loại thông tin nào cần được đăng ký và theo

những cách nào, cũng như cách thông tin tạo ra cho các báo cáo trạng thái. Cách

hay là dùng cơ sở dữ liệu thay vì biểu diễn thông tin trực tiếp lên file, mặc dù điều

này hơi nặng nề. Nhưng dễ tạo ra một bảng báo cáo từ cơ sở dữ liệu hơn là đọc qua

số lượng lớn các dòng ghi chú trong file

Những yếu tố dữ liệu khác

Một thành phần quản lý cấu hình có thề có thêm những phần dữ liệu thích hợp

để đăng ký ngoài những thông tin chỉ ra ở trên. Có thể là tên đầy đủ, mô tả tên thêm

để bổ sung cho tên định danh..

2.5.2.2 Siêu dữ liệu dùng để chỉ ra sự nhận biết duy nhất

Mỗi một thành phần cấu hình phải có cách nhận biết duy nhất, được hình

thành từ một hay nhiều nhóm dử liệu ở hình dưới.

Hình 2-9 Siêu dữ liệu nhận biết sự duy nhất

Thuộc về

“Thuộc về” chỉ ra thực thể tham gia vào những thành phần nào. Một thực thể

cấu hình thường thuộc về một sản phẩm. Trong một vài trường hợp, các thành phần

quản lý cấu hình có thể thuộc về một vài sản phẩm như các thành tố - component.

Trang 46

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Trong những trường hợp như vậy, khi sử dụng, phải chỉ ra thực thể cấu hỉnh thuộc

về một nhóm thành tố nào

Tên

Tên của một thành phần cấu hình có thể được xây dựng bằng nhiều cách.

Thông thường nó sẽ là sự kết hợp của text, loại, số, .. và có ý nghĩa riêng.

Part Function

Text Text có thể mô tả những chữ viết tắt nơi thành phần cấu hình thuộc về

và chức năng của nó. Đối với đối tượng mã nguồn, text thông thường

kết hợp với dấu hiện ngắn nói lên mục đích của đoạn mã (ví dụ:

CUS_ADD dùng cho đoạn mã liên quan đến xử lý địa chỉ của khách

hàng)

Type Chỉ ra loại sản phẩm của thành phần quản lý. Mô tả loại có thể là một

mức độ chung như DOC đối với tài liệu, COD đối với mã nguồn. Mô tả

loại cũng áp chỉ đến mức chi tiết hơn như PMP là “Kế hoạch quản lý đề

án” hoặc PSC là đoạn code được viết bằng Pascal. Đặc biệt quan trọng

chỉ ra loại cụ thể nếu chỉ là sự khác nhau giữa các thành phần cấu hình.

Ví dụ như hai tài liệu giống nhau được viết bằng Word và WordPerfect

Running Phân biệt giữa các thành phần cấu hình của cùng một loại. Đây không

number phải là số phiên bản của thành phần quản lý cấu hình mà là những số cá

nhân. Ví dụ là ghi chý kỹ thuật chỉ ra như TN_nnnn, NT là mô tả loại

và nnnn là số đang chạy

Bảng 2-4 Thành phần tên và chức năng của nó

Phiên bản

Phiên bản mô tả quá trình phát triển của một thành phần cấu hình. Thông tin

phiên bản có thể chỉ là cách phân biệt giữa hai thành phần cấu hình, vì mỗi phiên

bản được coi như một thành phần riêng rẽ. Khi một thành phần cấu hình mới được

phát triển dựa trên cơ bản một thành phần đã tồn tại rồi, tất cả những phần để nhận

biết thường được kế thừa.

Trang 47

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Thông tin trên một phiên bản có thể chứa một vài tầng, tuỳ thuộc vào mức độ

chi tiết mong muốn lưu trữ. Hơn nữa có nhiều cách đặt tên và diễn tả thông tin theo

cấu trúc đặc tên phân tầng

Trạng thái

Trạng thái mô tả trạng thái hiện tại của thành phần cấu hình. Cần phải chỉ ra

trạng thái của thực thể cấu hình để mọi người biết để có thể dùng thực thể cấu hình

đó hay không.

Ngày

Ngày là ngày tạo version.

Nơi lưu trữ

Nơi lưu trữ vật lý của thực thể cấu hình. Nó sẽ giúp dễ tìm các thực thể. Nơi

lưu trữ có thể hoàn toàn cụ thể ở một nơi nào khác nữa, như là một cấu trúc cây thư

mục trên máy chủ mô tả trong kế hoạch quản lý cấu hình cho tất cả các thành phần

của cùng một loại. Nơi lưu trữ được biểu diễn bằng đường dẫn tuyệt đối, hoặc

đường dẫn tương đối theo quy ước

Bộ lưu trữ trung gian

Ví dụ các trạng thái của một tài liệu

Dưới đây là một vài trạng thái thường gặp của các tài liệu:

Dưới sự chuẩn bị: chỉ ra cái sẽ thực hiện, nhưng thành phần chưa đưa vào

quản lý cấu hình. Nó không thể dùng bởi một người nào khác ngoại trừ nhà sản xuất

và các sự kiện chưa đăng ký (quản lý phiên bản)

Dưới sự kiểm soát chất lượng: thành phần dưới sự kiểm soát cấu hình nhưng

chỉ dùng cho các hoạt động đảm bảo chất lượng (ví dụ: kiểm tra). Các sự kiện được

đăng ký

Chấp nhận: thành phần được chấp nhận qua các hoạt động chất lượng và mọi

người có thể dùng. Những sự kiện được đăng ký

Ví dụ về bộ mã nguồn

Bảng chỉ ra ví dụ các trạng thái của một đơn vị mã nguồn trong quá trình phát

triển.

Trang 48

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Activity/State Unit Status Responsible

Development, ongoing Busy Developer

Development, pausing Saved Developer

Unit CI in "useful" state Proposed Developer

Unit undergoing formal unit test Proposed Approver signature

Formal unit test ready for approval Proposed Developer

Formal unit test is approved Proposed Approver signature

Formal unit release established Published Configuration

management

Build undergoing formal integration Proposed Integrator

Formal integration test is ready for Proposed Integrator

approval

Formal integration test is approved Proposed Test manager signature

Formal build release established Published Configuration

management

Các trạng thái của một đơn vị có thể :

• Bận: đảm bảo quản lý phiên bản, không một ai có thể tình cờ bắt đầu thay

đổi cùng trên một file mã nguồn

• Lưu: Chỉ ra phiên bản đang thuộc riêng về nhà phát triển

• Đề xuất (Proposed): chỉ ra phiên bản đang trong trạng thái có ích với các

nhà phát triển khác. Chỉ những phiên bản với trạng thái (“proposed”) hay

cao hơn có thể dùng chính thức trong các unit tests

• Xuất (Published): phiên bản đã được test (unit test) và được chấp nhận

• Truy cập(Accessed): Phiên bản đã được chấp nhận chính thức sau lần kiểm

tra tích hợp

• Frozen: chỉ ra phiên bản là một phần của release chính thức

Trang 49

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.5.2.3 Siêu dữ liệu cho việc phân trách nhiệm

Việc phân trách nhiệm chỉ ra một người có quyền làm gì và đã làm gì với các

thực thể cấu hình. Việc phân trách nhiệm có thể gồm các dữ liệu như hình dưới

Hình 2-10 Siêu dữ liệu cho việc phân trách nhiệm

Thông thường, một đề án phần mềm có 3 loại người chịu trách nhiệm mô tả

bằng mối quan hệ “được tạo ra bởi”, “dưới sự quản lý của” và “được chấp thuận

bởi”.

Một hợp đồng cũng đòi hỏi nhóm đại diện của khách hàng chịu trách nhiệm về

tài liệu đăc tả yêu cầu cũng như toàn hệ thống

Nhà sản xuất

Là người chịu trách nhiệm tạo ra thực thể và đặt nó vào quản lý cấu hình. Nhà

sản xuất có thể là người tạo ra phiên bản mới dựa vào quản lý yêu cầu. Đối với mã

nguồn, nhà sản xuất thường là người lập trình. Đối với các tài liệu, nhà sản xuất là

tác giả, các tài thiệu về thiết kế nhà sản xuất là nhà thiết kế, các kế hoạch của đề án

nhà sản xuất là các nhà quản lý đề án.

Người giữ tất cả các trách nhiệm

Người giữ tất cả các trách nhiệm có trách nhiệm sau cùng với việc sửa lỗi sản

phẩm và các bản giao. Người này có thể là người quản lý đề án hoặc là một nhóm

quản lý dưới quyền người quản lý đề án hoặc người chịu trách nhiệm kiểm thử.

Trang 50

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Người chịu trách nhiệm phê duyệt

Người chịu trách nhiệm phê duyệt có thể là nhà sản xuất trong các hoạt động

quản lý cấu hình sớm hoặc không chính thức. Người này có thể là người chịu trách

nhiệm về chất lượng trong quản lý cấu hình với mức độ hình thức cao, hoặc là một

nhóm các nhà thầu khoán khi quản lý cấu hình thực hiện với mức độ hình thức cao.

Người chịu trách nhiệm phê quyệt cũng có thể có vai trò như ban quản lý cấu hình,

chịu trách nhiệm phê duyệt tất cả những thay đổi đối với một thực thể cấu hình và

quyết định xem một thực thể đã sẵn sàng được quản lý cấu hình hay không.

Quyền sở hữu

Mô tả người có thể rút một thực thể để sản xuất và có thể làm thay đổi thực

thể đó. Nhưng ban quản lý cấu hình sẽ quyết định ai có thể làm thay đổi một thực

thể (tạo ra phiên bản mới) khi thực thể được đặt dưới sự quản lý cấu hình.

2.5.2.4 Siêu dữ liệu chỉ mối quan hệ đến các thực thể cấu hình khác

Thực tế, tất cả các thực thể cấu hình có một hay nhiều quan hệ với các thực

thể khác. Các mối quan hệ sẽ thường được mô tả bởi các dữ liệu ở hình dưới.

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

Theo vết

Thông tin để theo vết đối với một thực thể cấu hình cung cấp lý do tồn tại của

thực thể… Theo dõi thực thể từ những hoạt động trong quá trình phát triển của thực

Trang 51

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

thể cấu hình. Thông thường, kế hoạch đề án sẽ chỉ ra các thực thể cấu hình nào theo

dõi lẫn nhau: Theo dõi có thể thực thiện theo mô hình V

• Yêu cầu phần mềm dựa vào yêu cầu của người dùng

• Việc chấp nhận đặc tả test dựa vào những yêu cầu người dùng

• Thiết kế kiến trúc dựa vào yêu cầu phần mềm

• Chi tiết thiết kế dựa vào thiết kế kiến trúc và yêu cầu phần mềm ,v.v..

Đây chỉ là một phần nhỏ các thông tin theo vết có thể của sản phẩm. Nhìn

chung, nó có thể theo dõi tất cả các thực thể cấu hình để định trước các thực thể cấu

hình. Hình dưới chỉ ra theo dõi một đặc tả yêu cầu và một đặc tả kiểm tra hệ thống.

Hình 2-12 Ví dụ của việc theo vết

Đăng ký theo vết

Việc theo dõi thường là quan hệ nhiều nhiều. Để theo dõi thì thực thể cấu hình

phải có định danh duy nhất không thay đổi, dễ tham khảo và có thể truy cập được.

Việc theo dõi phải đăng ký theo cách báo cáo dễ để theo dõi cả hai phía. Có

nghĩa là nó có thể tìm ra các testcase đối với một yêu cầu cụ thể và các yêu cầu

phần mềm cho một testcase nào.

Phiên bản mới của thực thể cấu hình sẽ thường kế thừa các theo dõi của các

phiên bản trước. Việc theo dõi sẽ được kiểm soát, vì thế việc theo dõi được lưu trữ

lại và vẫn còn đúng với tất cả các phiên bản khác.

Tầm quan trọng của việc theo vết

Việc theo dõi là một phần đăng ký thường bị bỏ quên, vì nó là nhiệm vụ lớn

và hầu như không khả thi. Việc theo vết khó thực nếu bắt đầu theo vết ở giữa đề án.

Trang 52

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Tuy nhiên, điều này có thể thực hiện được nhờ vào công nghệ đảo để tạo ra thông

tin theo dõi cho các thực thể cấu hình

Việc theo dõi thì quan trọng đối với người tạo ra thực thể cấu hình và đặc biệt

đối với những ai thay đổi chúng. Chất lượng sẽ được cải tiến khi người ta hiểu mối

quan hệ giữa các thực thể trong hệ thống.

Việc theo vết cũng được dùng để tìm ra kiểm tra kép việc thiết kế. Nếu một

yêu cầu theo vết với số lượng lớn các thực thể thiết kế, nó có thể là một dấu hiệu

thiết kế quá phức tạp và cần phải xem xét lại

Tạo ra với

Nói lên công cụ nào dùng để tạo nên thực thể. Không phải lúc nào cũng cần

đặt công cụ dưới sự quản lý cấu hình hoặc công cụ nào tạo ra thực thể nào. Với các

thực thể trong một bản phân phối, nên chỉ ra cái gì được dùng để nối kết các thực

thể cấu hình thành phiên bản để sử dụng.

Dẫn xuất từ

Mô tả lịch sử của thực thể cấu hình, phiên bản được thay đổi do phiên bản

trước nào. Nó chỉ xảy ra nếu có sự thay đổi phiên bản.

Bao gồm

Chỉ có các delivery mới bao gồm các thực thể cấu hình. Một module mã

nguồn không bao gồm các thực thể cấu hình khác, nhưng một yêu cầu phát hành

của phần mềm bao gồm bản kế hoạch của đề án, đặc tả người dùng, đặt tả yêu cầu

phần mềm và kế hoạch kiểm thử hệ thống.

2.6 Hệ thống quản lý cấu hình phần mềm

2.6.1 Khái niệm:

Hệ thống quản lý cấu hình phần mềm của một tổ chức lưu giữ các thông tin

quan trọng về việc phát triển sản phẩm, triển khai và quản lý tiến trình, và giữ lại

những kết quả có thể sự dụng lại sau này.

Trang 53

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

2.6.2 Mục tiêu

Hệ thống quản lý cấu hình phần mềm cần được thiết kế để kiểm sóat số lượng

lớn các sưu liệu được phát sinh từ nhiều người trong một dự án. Nhằm mục đích

tránh lãng phí chi phí và đảm bảo không bị trùng lắp khi tiến hành tích hợp hệ

thống.

2.6.3 Lợi ích

Một số lợi ích mà hệ thống quản lý cấu hình có thể đem lại là:

• Quản lý tính toàn vẹn của sản phẩm.

• Đảm bảo tính đầy đủ và chính xác của sản phẩm.

• Cung cấp môi trường ổn định để phát triển sản phẩm.

• Hạn chế thay đổi yêu cầu dựa trên nguyên tắc của dự án.

• Kiểm sóat những sưu liệu bị thay đổi thông qua trả lời câu hỏi: tại sao, khi

nào, và ai đã thay đổi.

2.6.4 Các tiến trình con trong quản lý cấu hình phần mềm

Nói chung, một hệ thống cấu hình phần mềm cụ thể sẽ liên quan đến một giải

pháp và qui định quản lý cấu hình phần mềm được công bố trong sổ tay quản lý cấu

hình của công ty. Các giải pháp và qui định này có thể xuất phát từ các chuẩn tổng

quát IEEE 828-1983, ISO 9000, CMM , CMMI ...

Hệ thống quản lý cấu hình bao gồm những họat động chính sau:

Tiến trình lập kế hoạch quản lý cấu hình chi tiết cho sản phẩm sẽ phát triển: là

tiến trình này thiết lập việc quản lý cấu hình, các thực thể sẽ được quản lý trong hệ

thống quản lý cấu hình phần mềm và vai trò của các thành viên trong hệ thống phần

mềm cho một đề án cụ thể.

Tiến trình quản lý những thay đổi về cấu hình phần mềm: là tiến trình bao

gồm vịêc phân tích các thay đổi, đánh giá phí tổn và theo dõi “vết” của thay đổi.

Tiến trình quản lý phiên bản của sản phẩm: tiến trình định nghĩa, theo dõi và

kiểm sóat các phiên bản khác nhau của một hệ thống phần mềm.

Trang 54

Chương 2 - Tổng quan về quản lý cấu hình phần mềm

Tiến trình tích hợp sản phẩm từ các thành tố: là tiến trình tổ hợp các thành tố

của hệ thống thành một chương trình có thể thực hiện trên một môi trường cấu hình

cụ thể. Với hệ thống lớn đây là một tiến trình quan trọng trong quản lý cấu hình.

Hình 2-13 Sơ đồ các tiến trình con trong quản lý cấu hình

Các tiến trình trên liên quan đến các thành viên tham gia vào quá trình phát

triển phần mềm và được hỗ trợ bởi các công cụ phát triển phần mềm ở mức tự động

hoặc bán tự động.

Trang 55

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Chương 3 Quản lý cấu hình phần mềm trong

CMM & CMMI

3.1 Mô hình trưởng thành

Capability Maturity Model (CMM) version 1.1 là mô hình được sử dụng rộng

rãi nhất. Nó được phát triển và được hỗ trợ bởi viện Công Nghệ Phần mềm ở đại

học Carnegie Mellon. Version 1.0 được phát hành vào 1991. Version 1.1 được phát

hành vào 1993. Version 2.0 vẫn đang thực hiện, nhưng có vẻ version này được thay

thế bởi CMMI. Do đó, ta sẽ đề cấp đến quản lý cấu hình trong CMM version 1.1 và

CMMI

3.2 CMM version 1.1

3.2.1 Mức độ trưởng thành của CMM Version 1.1

Level 1:

Khởi động

Level 2: Quản lý cấu hình phần mềm

Lặp lại Quản lý chất lượng phần mềm

Quản lý các hợp đồng phụ

Theo dõi và giám sát đề án phần mềm

Lập kế hoạch cho đề án phần mềm

Những yêu cầu về quản lý

Level 3: Công tác xem xét

Được định nghĩa Sự hợp các giữa các nhóm

Sản phẩm phần mềm

Quản lý phần mềm tích hợp

Trang 56

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Chương trình huấn luyện

Định nghĩa tiến trình

Tập trung cũng cố tiến trình

Level 4: Quản lý thay đổi quy trình

Quản lý Quản lý thay đổi công nghệ

Ngăn chặn lỗi

Level 5: Quản lý chất lượng phần mềm

Tối ưu hoá Quản lý quy trình chất lượng

Bảng 3-1 Mức độ trưởng thành của CMM

Quản lý cấu hình là một vùng tiến trình chính ở mức phát triển mức 2. Để đạt

được chuẩn 2, công ty phải đạt những mục tiêu trong tất cả các vùng tiến trình chính

ở mức phát triển cấp 2, bao gồm quản lý cấu hình. Những mục đích để quản lý cấu

hình trong CMM version 1.1 là:

Mục tiêu 1: Lên kế hoạch những hoạt động Quản lý cấu hình

Mục tiêu 2: Chỉ rõ và kiểm soát những công việc để làm ra sản phẩm.

Mục tiêu 3: Những thay đổi của sản phẩm công nghệ phần mềm được kiểm

soát

Mục tiêu 4: Những nhóm và những cá nhân ảnh hưởng sẽ được thông báo về

trạng thái và nội dung của các cấu hình cơ sở (baselines) của phần mềm

3.2.2 Quản lý cấu hình phần mềm trong CMM version 1.1

3.2.2.1 Mục đích

Mục đích của Quản lý cấu hình là thiết lập và lưu lại sự tích hợp của những

sản phẩm thông qua quy trình phát triển phần mềm. Hệ thống Quản lý cấu hình là

phần tích hợp hầu hết các quy trình phần mềm và quy trình quản lý.

3.2.2.2 Các hoạt động của quản lý cấu hình trong CMM Version 1.1

Hoạt động 1:

Trang 57

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Một kế hoạch Quản lý cấu hình được chuẩn bị cho mỗi đề án phần mềm tùy

vào một tài liệu quy trình

Hoạt động 2:

Một kế hoạch về Quản lý cấu hình được chấp nhận và ghi thành tài liệu dùng

để làm nền tảng để thực hiện những hoạt động về Quản lý cấu hình

Hoạt động 3:

Một hệ thống thư viện quản lý cấu hình được thiết lập như là một kho chứa

những cấu hình cơ sở của phần mềm

Hoạt động 4:

Chỉ ra và quản lý những công việc để tạo sản phẩm

Hoạt động 5:

Thay đổi yêu cầu và những báo cáo lỗi đối với những thực thể cấu hình được

khởi tạo, lưu lại, kiểm tra, chấp thuận, và theo dõi dựa vào tài liệu quy trình

Hoạt động 6:

Thay đổi các cấu hình cơ sở sẽ được kiểm soát, theo dõi theo tài liệu quy trình

Hoạt động 7:

Tạo ra những sản phẩm từ thư viện cấu hình cơ sở của phần mềm và những

bản phát hành sẽ được kiểm soát theo một tài liệu quy trình

Hoạt động 8:

Trạng thái của thực thể cấu hình/ bộ cấu hình được lưu lại theo một tài liệu

quy trình

Hoạt động 9:

Những tài liệu báo cáo chuẩn về những hoặc động Quản lý cấu hình và nội

dung của cấu hình cơ sở phần mềm được phát triển và giao cho những nhóm và

những cá nhân có liên quan

Hoạt động 10:

Kiểm tra cấu hình cơ sở của phần mềm theo một tài liệu quy trình

Trang 58

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

3.3 Quản lý cấu hình trong CMMI

3.3.1 Các mức trưởng thành của CMMI

Hình 3-1 các mức trưởng thành của CMMI

Mức trưởng thành Vùng tiến trình

Phân tích nguyên nhân và giải pháp

5 Đổi mới tiến trình công nghệ Tối ưu hoá

4 Hiệu năng tiến trình

Được quản lý nhờ vào định lượng Quản lý đề án định lượng

3 Phát triển yêu cầu

Được định nghĩa Giải pháp kỹ thuật

Tích hợp sản phẩm

Kiểm tra

Xác nhận

Tập trung cũng cố tiến trình

Định nghĩa tiền trình

Huấn luyện

Quản lý đế án tích hợp

Tích hợp nhóm

Trang 59

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Quản lý rủi ro

Tích hợp quản lý với nhà cung cấp

Phân tích quyết định và giải pháp

Tích hợp môi trường tổ chức

2 Quản lý yêu cầu

Được quản lý Hoạch định đề án

Theo dõi và kiểm soát đề án

Quản lý hợp đồng với nhà cung cấp

Đo lường và phân tích

Bảo đảm chất lượng sản phẩm và tiến trình

Quản lý cấu hình

Khởi động

Bảng 3-2 Các mức trưởng thành và các vùng tiến trình của CMMI

3.3.2 Quản lý cấu hình trong CMMI

3.3.2.1 Mục đích

Mục đích của Quản lý cấu hình là thiết lập và duy trì tính toàn vẹn của các sản

phẩm kết xuất nhờ vào việc định danh cấu hình, kiểm soát cấu hình, xác định trạng

thái cấu hình và kiểm tra cấu hình.

3.3.2.2 Các hoạt động

• Chỉ ra cấu hình của một sản phẩm được chọn bao gồm cấu hình cơ sở tại

thởi điểm chỉ ra

• Kiểm soát thay đổi đối với những thành phần trong cấu hình

• Xây dựng hoặc cung cấp những đặc tả để xây dựng sản phẩm từ hệ thống

Quản lý cấu hình

• Lưu trữ sự tích hợp các cấu hình cơ sở

Trang 60

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

• Cung cấp trạng thái chính xác và cấu hình hiện tại cho những nhà phát triển

phần mềm, những người dùng cuối, khách hàng. Công việc được kiểm soát

dưới sự quản lý cấu hình bao gồm những sản phẩm được giao cho khách

hàng, chỉ ra các sản phẩm nội bộ bên trong, những sản phẩm thu được,

những công cụ và những thành phần khác được dùng để tạo và mô tả những

sản phẩm.

Đối với gia công phần mềm

Sản phẩm làm ra cần được kiểm soát cấu hình bởi cả nhà cung cấp và đề án.

Cần phải thiết lập trong hợp đồng về việc thực hiện quản lý cấu hình. Cần phải đưa

ra, duy trì các phương pháp phù hợp để đảm bảo về tòan vẹn dữ liệu

Những ví dụ về những công việc tạo nên sản phẩm được đặt dưới sự quản lý

cấu hình gồm:

• Kế hoạch

• Mô tả qui trình

• Những yêu cầu

• Thiết kế dữ liệu

• Những bản vẽ

• Đặc tả sản phẩm

• Mã nguồn

• Trình biên dịch

• File dữ liệu của sản phẩm

• Tài liệu kỹ thuật về sản phẩm

3.3.2.3 Những vùng tiến trình liên quan

Liên quan đến vùng tiến trình Lập kế hoạch đề án gồm những thông tin liên

quan đến kế hoạch phát triển, cấu trúc phân chia công việc. Điều này thuận lợi cho

việc quyết định cần theo dõi những thành phần nào cần quản lý cấu hình

Trang 61

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Liên quan đến vùng tiến trình phân tích nguyên nhân và giải pháp để tìm ra

thêm thông tin về phương pháp sử dụng để phân tích ảnh hưởng của thay đổi yêu

cầu và phương pháp sử dụng khi việc ước lượng thay đổi

Liên quan đến vùng tiến trình Theo dõi và kiểm soát đề án để có nhiều

thông tin về việc phân tích thực hiện và những hành động sửa chữa

3.3.2.4 Các mục tiêu chuyên biệt

SG 1 Thiết lập các nhóm đối tượng cấu hình cơ sở

Chỉ ra các công việc nào cần được xác lập cấu hình cơ sở

SG 2 Theo dõi và kiểm soát những thay đổi

Những thay đổi về sản phẩm phải được kiểm soát của Quản lý cấu hình, chúng

được lưu vết và được kiểm soát

SG 3 Thiết lập tính tòan vẹn cấu hình

Ghi nhận và lưu sự tòan vẹn của các cấu hình cơ sở

3.3.2.5 Các mục tiêu tổng quát

GG 1 Đạt những mục tiêu cụ thể

GG 2 Chuẩn hoá một quy trình quản lý

GG 3 Chuẩn hoá một định nghĩa quy trình

GG 4 Chuẩn hoá một quy trình quản lý định lượng

GG 5 Chuẩn hoá một quy trình lạc quan

3.3.2.6 Mối quan hệ giữa mục tiêu và thực tiễn

SG 1 Thiết lập các cấu hình cơ sở

• SP 1.1-1 Chỉ ra các thực thể cấu hình

• SP 1.2-1 Thiết lập một hệ thống quản lý cấu hình

• SP 1.3-1 Tạo hoặc phát hành một cấu hình cơ sở

SG 2 Lưu vết và kiểm soát thay đổi

• SP 2.1-1 Lưu vết các thay đổi yêu cầu

• SP 2.2-1 Điều khiển các thành phần quản lý cấu hình

Trang 62

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

SG 3 Thiết lập sự tòan vẹn

• SP 3.1-1 Chuẩn bị hồ sơ Quản lý cấu hình

• SP 3.2-1 Thực hiện kiểm tra cấu hình

GG 1 Đạt những mục đích cụ thể

• GP 1.1 Thực hiện những thói quen cơ bản

GG 2 Thể chế hoá một quy trình quản lý

• GP 2.1 Thiết lập một quy định có tổ chức

• GP 2.2 Lên kế hoạch quy trình

• GP 2.3 Cung cấp những tài nguyên

• GP 2.4 Gián trách nhiệm

• GP 2.5 Huấn luyện con người

• GP 2.6 Quản lý cấu hình

• GP 2.7 Xác định những người thầu khoán có liên quan

• GP 2.8 Quản lý và kiểm soát quy trình

• GP 2.9 Đánh giá một cách khách quan sự tham gia

• GP 2.10 Kiểm tra trạng thái với cấp độ quản lý cao hơn

GG 3 Chuẩn hoá việc định nghĩa quy trình

• GP 3.1 Thiết lập một quy trình định nghĩa

• GP 3.2 Thu thập các thông tin cải tiến

GG 4 Chuẩn hoá một quy trình quản lý định lượng

• GP 4.1 Thiết lập mục tiêu định lượng quy trình

• GP 4.2 Ổn định hoá các hiệu năng tiến trình phụ

GG 5 Chuẩn hoá một quy trình khách quan

• GP 5.1 Đảm bảo cải tiến liên tục quy trình

• GP 5.2 Sửa nguyên nhân gốc gây ra lỗi

Trang 63

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

3.3.2.7 Các thực tiễn cụ thể trong từng mục đích

SG 1 Thiết lập các cấu hình cơ sở

SP 1.1 – 1 Xác định các thực thể cấu hình

SP 1.2 – 1 Thiết lập hệ thống quản lý cấu hình

SP 1.3 – 1 Tạo lập các nhóm cấu hình cơ sở và phát sinh sản phẩm

chuyển giao

Bảng 3-3 Danh sách các thực tiễn cho cho SG 1

SG 2 Theo vết và kiểm soát thay đổi

SP 2.1 – 1 Theo dõi các yêu cầu thay đổi

SP 2.2 – 1 Kiểm soát thay đổi thực thể cấu hình

Bảng 3-4 Danh sách các thực tiễn cho cho SG 2

SG 3 Thiết lập sự toàn vẹn cấu hình

SP 3.1 – 1 Thiết lập hồ sơ quản lý cấu hình

SP 3.2 – 1 Thực hiện kiểm tra quản lý cấu hình

Bảng 3-5 Danh sách các thực tiễn cho cho SG 3

SG 1 Thiết lập cấu hình cơ sở

Chỉ ra những sản phẩm cấu hình cơ sở

Thiết lập cấu hình cơ sở, theo dõi và kiểm soát những thay đổi để duy trì cấu

hình cơ sở, thiết lập sự tích hợp, ghi tài liệu và kiểm tra sự tích hợp của các cấu hình

cơ sở

SP 1.1-1 Chỉ ra những thực thể quản lý cấu hình

Chỉ ra những thực thể cấu hình, những thành tố, và những công việc liên quan

được kiểm soát bởi quản lý cấu hình

Định danh cấu hình được chọn, tạo ra, đặc tả như sau:

• Sản phẩm giao cho khách hàng

Trang 64

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

• Chỉ rõ những công việc thực hiện bên trong

• Sản phẩm đạt được

• Những công cụ

Những thành phần khác được dùng để tạo và mô tả những công việc để tạo

nên sản phẩm

Những thực thể cấu hình đặt dưới sự kiểm soát cấu hình sẽ bao gồm những

đặc tả và những tài liệu giao tiếp nêu lên định nghĩa những yêu cầu của sản phẩm.

Những tài liệu khác tuỳ thuộc vào mức độ quan trọng của nó vào sản phẩm cũng có

thể bao gồm trong quản lý cấu hình như kết qủa kiểm tra.

Một “thực thể cấu hình” là một thực thể được thiết kế để quản lý cấu hình, nó

có thể bao gồm nhiều sản phẩm liên quan tới một cấu hình cơ sở. Nhóm logic này

cung cấp sự định danh ra và điều khiển sự truy cập. Sự lựa chọn công việc để quản

lý cấu hình nên dựa trên một tiêu chuẩn được thiết lập trong khi lập kế hoạch

Typical Work Products

Chỉ ra những thực thể cấu hình

Subpractices

Chọn những thực thể cấu hình và sản phẩm dựa trên tiêu chuẩn mô tả trên tài

liệu

Ví dụ tiêu chuẩn chọn những thực thể cấu hình vào những công việc theo cấp

thích hợp như sau:

• Sản phẩm công việc có thể được sử dụng bởi hai hay nhiều nhóm.

• Sản phẩm công việc luôn bị thay đổi vì lỗi hoặc thay đổi yêu cầu.

• Sản phầm công việc thì phụ thuộc lẫn nhau, do đó, khi thay đổi một trong

những thành phần, sẽ làm thay đổi những thành phần khác.

• Sản phẩm công việc là tiêu chuẩn để đánh giá đề án

Những ví dụ về sản phẩm có thể là thành phần của quản lý cấu hình bao gồm:

• Những định nghĩa quy trình

• Những yêu cầu

Trang 65

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

• Thiết kế

• Kế hoạch kiểm thử và quy trình kiểm thử

• Kết qủa kiểm tra

• Những mô tả giao tiếp

+ Gán định danh duy nhất cho những đối tượng quản lý cấu hình

+ Đặc tả những tính chất quan trọng của mổi thực thể cấu hình

Ví dụ những tính chất của thực thể cấu hình bao gồm tác giả, tài liệu, loại file,

ngôn ngữ lập trình, những file mã nguồn

+ Đặc tả khi thực thể cấu hình đặt dưới sự quản lý cấu hình

Những ví dụ để quyết định khi nàp đặt quản lý cấu hình cho công việc:

• Trạng thái trong quy trình phát triển

• Khi sản phẩm sẵn sàng cho việc kiểm thử

• Mức độ kiểm soát mong muốn trên công việc

• Giới hạn về chi phí và thời gian

• Những yêu cầu khách hàng

• Chỉ người chịu những trách nhiệm đối với mỗi thành phần cấu hình

SP 1.2-1 Thiết lập một hệ thống quản lý cấu hình

Thiết lập và bảo trì cấu hình và thay đổi hệ thống quản lý để đìều khiển công

việc

Hệ thống quản lý cấu hình bao gồm kho lưu trữ, thủ tục, và những công cụ

truy cập vào các đối tượng cấu hình

Thay đổi hệ thống quản lý bao gồm kho lưu trữ, thủ tục, và những công cụ để

lưu lại và truy cập thay đổi yêu cầu

Typical Work Products

Hệ thống quản lý cấu hình với các công việc hỗ trợ

Hệ thống quản lý cấu hình truy cập vào các thủ tục điều khiển

Thay đổi cơ sở dữ liệu yêu cầu

Subpractices

Trang 66

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Thiết lập một cơ chế quản lý cấu hình nhiều cấp

Ví dụ những tình huống quản lý nhiều bao gồm:

• Nhiều cấp quản lý tại những thời điểm khác nhau trong vòng đời của đề án

( kiểm soát chặt chẽ hơn khi sản phẩm sắp hòan thành)

• Những thay đổi trong các cấp cần quản lý đối với nhiều loại hệ thống (hệ

thống chỉ gồm phần mềm và hệ thống bao gồm phần cứng và phần mềm)

• Những khác biệt giữa các cấp cần quản lý phải thoả mãn yêu cầu bảo mật,

yêu cầu an tòan đối với những thực thể cấu hình

Lưu trữ và phục hồi những thực thể cấu hình trong hệ thống quản lý cấu hình

Những ví dụ hệ thống quản lý cấu hình bao gồm:

• Hệ thống động (hoặc hệ thống phát triển) bao gồm các thành phần hiện tại

đang được tạo ra hoặc kiểm tra. Chúng đang trong sự quản lý của các nhà

developer và kiểm soát bới các developer. Thành phần cấu hình trong cấu

hình động là kiểm soát phiên bản

• Hệ thống quản lý chính bao gồm những cấu hình cơ sở hiện tại, và thay đổi

chúng. Thành phần cấu hình trong một hệ thống lớn đặt dưới sự quản lý cấu

hình hòan chỉnh như được mô tả ở vùng tiến trình

• Những hệ thống bao gồm đạt những phiên bản phát hành cấu hình cơ sở để

sử dụng. Những hệ thống tĩnh được đặt dưới sự quản lý cấu hình như mô tả

trong vùng tiến trình

Chia sẽ và trao đổi thành phần cấu hình giữa những cấp quản lý trong hệ thống

quản lý cấu hình

Lưu lại và phục hồi những phiên bản đạt được của những thành phần cấu hình

Lưu giữ, cập nhật, phục hồi những dữ liệu cấu hình lưu lại

Tạo những báo cáo về quản lý cấu hình từ hệ thống quản lý cấu hình

Bảo quản nội dung của hệ thống quản lý cấu hình

Những ví dụ của những chức năng bảo quản của hệ thống quản lý cấu hình

bao gồm:

Trang 67

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

• Sao lưu và phục hồi những file quản lý cấu hình

• Đạt những file quản lý cấu hình

• Lưu lại những lỗi quản lý cấu hình

Kiểm tra lại cấu trúc quản lý cấu hình khi cần thiết

SP 1.3-1 Tạo hoặc phát hành cấu hình cơ sở

Tạo hoặc phát hành cấu hình cơ sở với mục đích sử dụng nội bộ hoặc giao cho

khách hàng

Một cấu hình cơ sở là một bộ những đặc tả hoặc những sản phẩm công việc

đang được kiểm tra và đạt được sự thỏa thuận. Sau đó nó là cơ bản để phát triển

nhiều hơn và chỉ thay đổi qua thay đổi quy trinh điều khiển. Một cấu hình cơ sở đại

diện cho công việc định danh các thực thể cấu hình và những thực thể liên quan

Một bộ những yêu cầu, thiết kế, file mã nguồn và những đoạn mã thực thi liên

quan, tài liệu người dùng (tất cả các thực thể liên quan) được gán sự định danh quy

nhất được xem là một cấu hình cơ sở.

Phát hành một cấu hình cơ sở, sửa chữa các file mã nguồn (những thành phần

cấu hình) từ hệ thống quản lý cấu hình và tạo ra những file thực thi. Một cấu hình

cơ sở được giao cho khách hàng thì thông thường gọi là một “phiên bản phát hành “

trong khi một cấu hình cơ sở sử dụng nội bộ thường gọi là “build”

Typical Work Products

Những cấu hình cơ sở

Mô tả các cấu hình cơ sở

Subpractices

Có sự cho phép của bộ quản lý cấu hình - configuration control board (CCB)

trước khi tạo hoặc phát hành baselines của những thành phần cấu hình

Tạo hoặc phát hành baselines chỉ từ những thành phần cấu hình trong hệ thống

quản lý cấu hình

Các tài liệu về các thực thể cấu hình cũng bao gồm trong cấu hình cơ sở

Có sẳn một cấu hình cơ sở hiện tại

SG 2 Theo dõi và kiểm soát thay đổi

Trang 68

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Những sản phẩm công việc đặt dưới sự quản lý cấu hình được theo dõi và

kiểm soát

Những quy tắc thực tiễn dưới mục tiêu chuyên biệt này để lưu trữ cấu hình cơ

sở sau khi chúng được thiết lập bới thực tiễn chuyên biệt dưới mục tiêu cụ thể Thiết

lập cấu hình cơ sở.

SP 2.1-1 Theo dõi thay đổi yêu cầu

Theo dõi thay đổi yêu cầu đối với những thành phần cấu hình

Thay đổi yêu cầu không chỉ những gồm những yêu cầu mới, yêu cầu thay đổi

mà còn gồm những lỗi trong sản phẩm.

Thay đổi yêu cầu được phân tích để quyết định ảnh hưởng thay đổi trên sản

phẩm công việc, những công việc liên quan, thời gian và chi phí

Typical Work Products

1. Thay đổi yêu cầu

Subpractices

Khởi tạo và lưu những thay đổi yêu cầu để thay đổi cơ sở dữ liệu yêu cầu

Phân tích ảnh hưởng của những thay đổi và sửa

Những thay đổi được đánh giá qua những hoạt động để đảm bảo chúng thống

nhất vói tất cả mặt kỹ thuật và yêu cầu đề án

Những thay đổi được đánh giá sự ảnh hưởng trực tiếp lên đề án và những yêu

cầu trong hợp đồng. Thay đổi tới một thực thể dùng trong nhiều sản phẩm có thể

gây ra vấn đề đối với những ứng dụng khác

Kiểm tra thay đổi yêu cầu sẽ được chỉ ra trong cấu hình cơ sở kế và thỏa thuận

để đạt sự đồng ý của những thành phần bị ảnh hưởng

Xem xét thay đổi yêu cầu bởi các thành viên tham gia. Lưu vị trí đối với

những thay đổi yêu cầu và lý do quyết định, bao gồm phạm vi thành công, mô tả

ngắn gọn kế hoạch hành động thích hợp. Thực hiện các hành động cần thực hiện

trong sự bố trí và ghi lại kết qủa cho các nhà thầu khoán.

Lưu vết trạng thái thay đổi yêu cầu đến khi nó kết thúc

Trang 69

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

SP 2.2-2 Kiểm soát những thực thể cấu hình

Kiểm soát những thay đổi của những thành phần cấu hình

Lưu lại việc kiểm soát cấu hình sản phẩm của cấu hình cơ sở. Điều khiển này

bao gồm theo dõi cấu hình của mỗi thực thể cấu hình, chấp nhận một cấu hình mới

nếu cần và cập nhật cấu hình cơ sở.

Typical Work Products

Kiểm soát lịch sử của những thực thể cấu hình

Đạt được các cấu hình cơ sở

Subpractices

Kiểm soát thay đổi của các thực thể cấu hình trong suốt vòng đời của sản

phẩm.

Đạt được sự chấp thuận trước khi thay đổi những thành phần cấu hình được

đưa vào trong hệ thống quản lý cấu hình

Ví dụ: sự chấp thuận từ Ban quản lý cấu hình, người quản lý đề án, khách

hàng

Check in và check out những thực thể cấu hình từ hệ thống quản lý cấu hình

để thống nhất những thay đổi để lưu lại các lần sửa lỗi và sự đồng bộ của các thành

phần quản lý cấu hình

Những ví dụ về những bước check in- check out bao gồm:

Xác nhận việc kiểm tra đã được chấp thuận

Cập nhật hệ thống quản lý cấu hình

Đạt những cấu hình cơ sở thay thế và lưu trữ cấu hình cơ sở mới

Thực hiện kiểm tra để đảm bảo những thay đổi không gây ra những ảnh hưởng

không mong muốn trên baseline (đảm bảo những thay đổi không có ảnh hưởng đến

sự an toàn và bảo mật cho lữ liệu ).

Lưu lại những thay đổi của các thành phần cấu hình và những lý do thay đổi

để phù hợp

SG 3 Thiết lập sự toàn vẹn cầu hình

Thiết lập và lưu lại sự tích hợp của các cấu hình cơ sở.

Trang 70

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Sự tích hợp của các cấu hình cơ sở được thiết lập bởi một quy trình liên quan

tới mục tiêu chuyên biệt thiết lập cấu hình cơ sở, và nó được bảo trì bởi mục tiêu

chuyên biệt về Theo dõi và kiểm soát thay đổi.

SP 3.1-1 Thiết lập hồ sơ quản lý cấu hình

Thiết lập và lưu lại các thông tin mô tả các thực thể cấu hình

Typical Work Products

Xem lại lịch sử của các thực thể cấu hình

Thay đổi nhật ký (log)

Sao chép những thay đổi yêu cầu

Trạng thái của các thực thể cấu hình

Sự khác nhau giữa các cấu hình cơ sở

Subpractices

Lưu lại các hành động quản lý cấu hình để có thể biết được nội dung và trạng

thái của mỗi thực thể cấu hình và có thể phục hồi những phiên bản trước đó.

Đảm bảo các nhà thầu khoán có thể truy cập và biết trạng thái của những thực

thể cấu hình

Chỉ ra phiên bản gần nhất của cấu hình cơ sở

Chỉ ra phiên bản của một thành phần cấu hình tạo nên một cấu hình cơ sở cụ

thể

Mô tả sự khác biệt giữa các cấu hình cơ sở thành công

Kiểm tra trạng thái và lịch sữ của mỗi thực thể cấu hình khi cần thiết.

SP 3.2-2 Thực hiện kiểm tra cấu hình

Thực hiện kiểm tra cấu hình để lưu lại sự tích hợp của cấu hình cơ sở

Kiểm tra các hoạt động và các tiến trình quản lý cấu hình để đảm bảo kết qủa

của cấu hình cơ sở và tài liệu là chính xác, lưu lại kết qủa kiểm tra.

Typical Work Products

Kết qủa kiểm tra cấu hình

Hành động của các thực thể.

Subpractices

Trang 71

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Ước lương sự tích hợp của cầu hình cơ sở

Khẳng định việc lưu lại cấu hình chính xác sẽ chỉ ra cấu hình của các thực thể

cấu hình

Kiểm tra cấu trúc và sự tích hợp của các thực thể trong hệ thống quản lý cấu

hình

Khẳng định sự hoàn toàn đầy đủ và chính xác cùa thực thể trong hệ thống

quản lý cấu hình

Xác nhận sự bằng lòng với các quy trình và tiêu chuẩn quản lý cấu hình

Theo dõi hành động các thực thể từ lúc kiểm tra cho đến khi kết thúc

3.3.2.8 Các thực tiễn chung cho từng mục đích

GG 1 Đạt những mục tiêu chuyên biệt

Quy trình hỗ trợ giúp đạt những mục tiêu chuyên biệt của vùng quy trình bằng

cách chỉ ra những sản phẩm đầu vào và tạo ra những sản phẩm đầu ra.

GP 1.1 Thực hiện những thực tiển cơ bản

Thực hiện những thực tiển cơ bản vào quy trình quản lý cấu hình giúp phát

triển sản phẩm và cung cấp những dịch vụ để đạt những mục tiêu cụ thể của vùng

tiến trình

GG 2 Chuẩn hoá một quy trình quản lý

Quy trình này được chuẩn hoá như một quy trình quản lý

GP 2.1 Thiết lập hợpđồng

Thiết lập và lưu giữ hợp đồng để lập kế hoạch và thực hiện quy trình quản lý

cấu hình

Chi tiết : Hợp đồng thiết lập những mong muốn về việc thiết lập và duy trì cấu

hình cơ sở (dưới sự quản lý cấu hình ) , và thiết lập và duy trì sự tích hợp của các

cấu hình cơ sở

GP 2.2 Lập kế hoạch quy trình

Lập và duy trì kế hoạch thực hiện quy trình quản lý cấu hình

Trang 72

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

Chi tiết: Kế hoạch để thực hiện quy trình quản lý cấu hình có thể bao gồm

(hoặc tham khảo đến) kế hoạch đề án.

GP 2.3 Cung cấp các nguồn tài nguyên

Cung cấp nguồn tài nguyên đầy đủ để thực hiện quy trình quản lý cấu hình,

phát triển sản phẩm, và cung cấp các dịch vụ cho quy trình

Chi tiết:

Ví dụ của nguồn tài nguyên bao gồm những công cụ sau:

Công cụ quản lý cấu hình

Công cụ quản lý dữ liệu

Công cụ lưu trữ và tái tạo

Chương trình cơ sở dữ liệu

GP 2.4 Giao trách nhiệm

Giao trách nhiệm thực hiện quy trình, phát triển sản phẩm, cung cấp dịch vụ

cho quy trình quản lý cấu hình

GP 2.5 Huấn luyện nhân viên

Huấn luyện nhân viên thực hiện hoặc hỗ trợ quy trinh quản lý cấu hình khi cần

Ví dụ đề tài huấn luyện bao gồm:

+ Vai trò, trách nhiệm, và quyền hạn của nhân viên quản lý cấu hình

+ Chuẩn quản lý cấu hình, quy trình và phương pháp

+ Hệ thống thư viện cấu hình

GP 2.6 Quản lý cấu hình

Đưa những sản phẩm tạo ra của quy trình quản lý cấu hình dưới cấp quản lý

cấu hình phù hợp

Những ví dụ sản phẩm đặt dưới sự quản lý cấu hình bao gồm:

+ Danh sách truy cập

+ Các báo cáo thay đổi trạng thái

+ Thay đổi cơ sở dữ liệu yêu cầu

+ Họp với ban quản lý cấu hình

+ Đạt những cấu hình cơ sở

Trang 73

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

GP 2.7 Chỉ ra những nhà thầu khoán liên quan

Ví dụ các hoạt động của nhà thầu khoán bao gồm:

+ Thiết lập các cấu hình cơ sở

+ Xem các báo cáo hệ thống quản lý cấu hình và giải quyết vấn đề

+ Tạo sự ảnh hưởng thay đổi trong các thực thể cấu hình

+ Thực hiện kiểm tra cấu hình

+ Xem kết qủa của kiểm tra cấu hình

GP 2.8 Quản lý và theo dõi quy trình

Quản lý và theo dõi quy trình quản lý cấu hình so với kế hoạch để thực hiện

quy trình và có hành động sửa lỗi nếu có.

Ví dụ các phép đo đùng trong theo dõi và kiểm tra bao gồm:

+ Số lượng thay đổi tới thực thể cấu hình

+ Số lượng cấu hình kiểm tra

GP 2.9 Đánh giá khách quan

Đánh giá một cách khách quan quy trình quản lý cấu hình theo mô tả của quy

trình, theo tiêu chuẩn, các quy trình

- Các hoạt động kiểm tra các hoạt động bao gồm

+ Thiết lập các cấu hình cơ sở

+ Theo dõi và kiểm soát thay đổi

+ Thiết lập và lưu giữ tích hợp của các cấu hình cơ sở

- Ví dụ kiểm tra sản phẩm bao gồm:

+ Đạt cấu hình cơ sở

+ Cơ sở dữ liệu thay đổi yêu cầu

GP 2.10 Kiểm tra trạng thái với mức độ quản lý cao hơn.

Kiểm tra các hoạt động, trạng thái, và kết qủa của quy trình quản lý cấu hình

với cấp quản lý cao hơn và giải quyết vấn đề

GG 3 Chuẩn hoá các quy trình định nghĩa

Quy trình được chuẩn hoá như một quy trình định nghĩa.

Trang 74

Chương 3 - Quản lý cấu hình phần mềm trong CMM & CMMI

GP 3.1 Thiết lập quy trình định nghĩa

Thiết lập và lưu trữ định nghĩa quy trình quản lý cấu hình

GP 3.2 Thu thập các thông tin để cải tiến

Sản phẩm có được, các phép đo, kết qủa đo, thông tin cải tiến từ kế hoạch và

thực hiện để hỗ trợ dùng cho tương lai và cải tiến các quy trình

GG 4 Chuẩn hoá quy trình quản lý định lượng

Quy trình được chuẩn hoá như một quy trình quản lý định lượng

GP 4.1 Thiết lập mục tiêu đánh giá định lượng của quy trình

Thiết lập và lưu giữ mục tiêu đánh giá cho quy trình quản lý cấu hình để chỉ

chất lượng và sự thực hiện dựa vào nhu cầu của khách hàng mục tiêu kinh doanh

GP 4.2 Ổn dịnh hoá hiệu năng của các tiến trình con

Ổn định hiệu năng của các quy trình con sẽ quyết định đến khả năng quy trình

quản lý cấu hình đạt mục tiêu chất lượng và hiệu năng.

GG 5 Chuẩn hoá một quy trình khách quan

Quy trình được chuẩn hoá như một quy trình khách quan

GP 5.1 Đảm bảo liên tục cải tiến quy trình

Đảm bảo liên tục cải tiến quy trình quản lý cấu hình trong việc đáp ứng các

mục tiêu thích hợp trong kinh doanh, của tổ chức

GP 5.2 Sửa đúng nguôn gốc lỗi gây ra vấn đề

Chỉ ra và sửa nguồn gốc lỗi gây ra lỗi và những vấn đề khác trong tiến trình

quản lý cấu hình

Trang 75

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

Chương 4 Vấn đề định danh, quản lý phiên bản

và các giải pháp

Trong các tiến trình con của tiến trình quản lý cấu hình phần mềm có rất nhiều

vấn đề mà người thực hiện việc quản lý cấu hình thường gặp phải:

• Việc đặt tên các đối tượng cấu hình

• Thiết lập cơ sở dữ liệu

• Xác định và định danh phiên bản

4.1 Đặt tên các đối tượng cấu hình

Các phương pháp đặt tên đối tượng cấu hình cần phải đảm bảo những điều

kiện sau:

• Mỗi đối tượng phải có tên duy nhất trong toàn bộ hệ thống quản lý cấu

hình.

• Tên đối tượng, nên xúc tích, gợi nhớ và hàm ý ý nghĩa của đối tượng.

• Cách đặt tên hàm ý hàm ý các mối quan hệ giữa các đối tượng được quản

lý. Chẳng hạn liên hệ giữa hồ sơ yêu cầu, thiết kế, mã nguồn và hồ sơ kiểm

tra cho một phiên bản của phần mềm cụ thể.

• Bản thân phương pháp đặt tên đối tượng phải được kiểm sóat bởi hệ thống

quản lý cấu hình (có thể tự động hoặc không), không được đặt tên tùy tiện.

4.1.1 Đặt tên phân cấp dựa theo cấu trúc cây.

Sự duy nhất của tên đối tượng được thể hiện bởi đường đi duy nhất từ gốc đến

mỗi nút trong cây phân cấp.

Mối liên hệ của các đối tượng thể hiện qua đối tượng có cùng chung nút cha,

các đối tượng có quan hệ cha con ...

Ví dụ:

PCL_TOOLS/EDIT/FORMS/DISPLAY/AST_INTERFACE/CODE

Trang 76

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

PCL_TOOLS/EDIT/HELP/QUERY/HELPFRAMES/FR_1

Hình 4-1 Cây phân cấp đặt tên

Điểm hạn chế:

• Phụ thuộc nhiều vào đề án cụ thể, làm giảm khả năng dùng lại của một

thành tố (chẳng hạn dùng lại một thành tố thì sao chép và đổi tên).

• Nếu dùng cách đặt tên để thiết kế hệ thống tập tin lưu trữ thì gặp khó khăn

trong trường hợp các đối tượng được truy xuất phân loại dựa vào các thuộc

tính khác nhau.

4.1.2 Đặt tên phân cấp dựa theo phương pháp tiền tố và hậu tố

Theo phương pháp đặt tên này, mội đối tượng cấu hình ngoài tên gọi có ý

nghĩa gợi nhớ và hàm ý ý nghĩa của đối tượng đó còn có thêm những thông tin khác

được thêm vào đầu tên đối tượng để đảm bảo tính duy nhất của đối tượng đó trong

hệ thống cấu hình.

Để rõ ràng, mỗi loại đối tượng cấu hình nên có một qui tắc đặt tên riêng. Chủ

yếu được phân làm hai loại: Hồ sơ văn bản (hồ sơ đặc tả, hồ sơ thiết kế) và mã

nguồn chương trình.

Sử dụng qui tắc đặt tên sau cho các tài liệu thuộc một dự án phần mềm cụ thể:

Trang 77

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

_..

Tên viết tắt Ý nghĩa

PPPP Tên dự án phần mềm mà tài liệu đó phụ thuộc vào

NNN Tên của loại tài liệu trong dự án phần mềm mà tài liệu đó thuộc

vào. Sử dụng từ viết tắt và được mô tả trong sổ tay “cấu hình

phần mềm” của công ty.

Vd:

URS: User requirement specification – Hồ sơ đặc yêu cầu

của người dùng.

OP: Operation Plan – Hồ sơ về kế họach thực hiện

MMM Tên gợi nhớ của tài liệu

TTT Phần mở rộng của tài liệu này

Bảng 4-1 Diễn giải từ viết tắt cho qui tắc đặt tên

Vd: Dự án quán lý về kế tóan có một hồ sơ đặc tả về một yêu cầu của

người dùng sẽ được đặt tên như sau:

QLKT_URS.yeucau_1.doc

Ưu điểm:

• Có thể dùng lại các đối tượng cấu hình đã phát triển cho đề án khác mà

không cần phải sao chép hoặc đổi tên đối tượng cấu hình đó.

Điểm hạn chế:

• Tên của đối tượng sẽ trở nên dài và vịêc nhớ được các từ viết tắt của tên tài

loại liệu sẽ gây khó khăn cho những người mới tham gia vào công ty hoặc

nếu số lượng từ viết tắt nhiều sẽ rất khó nhớ.

• Nếu tất cả các đối tượng cấu hình đều được đặt chung một chỗ trên hệ

thống sẽ gây khó khăn trong việc tìm kiếm và xác định các thành tố cho

người tích hợp phần mềm.

Trang 78

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

4.1.3 Nhận xét chung

Hai phương pháp đặt tên trên có thể được dùng độc lập hoặc kết hợp với nhau

để có được cách đặt tên đối tượng cấu hình phần mềm mới giải quyết được hai vấn

đề sau :

• Vấn đề trùng tên và dùng lại của các đối tượng cấu hình có thể được giải

quyết bằng phương pháp đặt tên theo tiền tố.

• Để giảm sự phức tạp của các thành tố do đặt chung vào một vị trí có thể xây

dựng một công cụ riêng để tạo ra một cấu trúc nhìn khác nhau cho những

đề án khác nhau. Hoặc sử dụng một công cụ có hỗ trợ tính năng tạo chia sẻ

(share) một đối tượng cấu hình vào nhiều vị trí khác nhau trên cấu trúc cây.

4.2 Xác định và định danh phiên bản

Việc xác định khi nào thì một phiên bản phần mềm mới được ra đời đã được

qui định trong việc lập kế họach cấu hình. Bên cạnh đó, người quản lý cấu hình cần

phải xác định được phương pháp định danh phiên bản cho phù hợp với phần mềm

cần phát triển.

Các phương pháp định danh phiên bản chỉ phản ánh được những mốc sự kiện

liên quan đến quá trình phát triển của phần mềm hoặc các phần tử cấu hình chứ

không cho biết các thuộc tính liên quan đến mỗi phiên bản phần mềm. Các thuộc

tính nên được lưu trong CSDL về quản lý cấu hình và bao gồm ít nhất những thông

tin sau đây:

• Tên khách hàng

• Ngôn ngữ dùng để phát triển.

• Tình trạng phát triển

• Cấu hình phần cứng

• Hệ điều hành

• Ngày lập phiên bản

Có 3 phương pháp định danh phiên bản chính:

• Sơ đồ tuyến tính

Trang 79

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

• Sơ đồ định danh theo dạng mạng

• Sơ đồ định danh theo tên

4.2.1 Sơ đồ tuyến tính

Sơ đồ nầy giả sử sự tiến hoá của hệ thống phần mềm diễn ra tuần tự, phiên bản

sau tương thích với phiên bản trước.

• Phiên bản đầu tiên thông thường là 1.0;

• Các phiên bản cơ sở là 1.0, 2.0, 3.0, …;

• Các phiên bản khác được bắt nguồn từ phiên bản cơ sở, ví dụ như bắt

nguồn từ phiên bản 2.0 là 2.1, 2.2, …

Phương pháp định danh này thích hợp cho những hệ thống phần mềm đơn

giản và việc định danh phiên bản có thể dựa trên việc check in hoặc check out của

hệ thống cấu hình.

4.2.2 Sơ đồ định danh theo mạng.

Sơ đồ định danh theo dạng mạng cho phép các phiên bản sau có thể được bắt

nguồn từ một phiên bản bất kỳ trong danh sách phiên bản hiện có của hệ thống

không nhất thiết phải từ phiên bản cơ sở trước đó. .

Trang 80

Chương 4 - Vấn đề định danh, quản lý phiên bản và các giải pháp

Hình 4-2 Sơ đồ định danh theo mạng

4.2.3 Sơ đồ định danh theo tên

Sử dụng phương pháp đặt tên phân cấp theo cấu trúc cây như trình bày ở trên.

Ví dụ: V1/VMS/DB Server: là phiên bản của DBServer chạy trên hệ điều hành

VMS

Trang 81

Chương 5 - Các công cụ hỗ trợ quản lý cấu hình

Chương 5 Các công cụ hỗ trợ quản lý cấu hình

5.1 Tóm tắt

Hiện nay, có rất nhiều công cụ tin học hỗ trợ việc quản lý cấu hình. Các công

cụ này có thể được cài đặt riêng lẻ hoặc được tích hợp vào toàn bộ tiến trình quản lý

cấu hình phần mềm.

• Cài đặt tích hợp gây khó khăn khi giao tiếp với các công cụ sẵn có.

• Cài đặt riêng lẻ linh động ít phí tổn và có thể tận dụng lại được các công cụ

sẵn có nhưng không thể theo dõi “vết” của các đối tượng trong suốt quá

trình quản lý cấu hình phần mềm.

Hai công cụ được trình bày trong chương này có thể được cài đặt riêng lẻ hoặc

tích hợp với một vài môi trường phát triển phần mềm tích hợp (IDE):

• Surround SCM 2.1.4 là một sản phẩm thương mại được phát triển bởi

Seapine Software Company.

• CVSNT được phát triển bởi Tony Hole. Công cụ này được cung cấp miễn

phí và được sử dụng rộng rãi trong cộng đồng mã nguồn mở GNU’s.

Xem hướng dẫn cài đặt và sử dụng 2 chương trình trên trong phần phụ lục A

5.2 Tính năng chung của Surround SCM và CVS

Hệ điều hành: Cả 2 công cụ trên đều hỗ trợ đa hệ điều hành trong đó có cá hệ

điều hành đang được sử dụng rộng rãi là Windows, Unix, Linux ...

5.3 Surround SCM

5.3.1 Mục đích

Surround SCM là một công cụ dùng để theo dõi sự thay đổi của mã nguồn

phần mềm dứơi những phiên bản khác nhau.

Trang 82

Chương 5 - Các công cụ hỗ trợ quản lý cấu hình

Surround SCM còn hỗ trợ việc phát triển phần mềm song song giải quyết vấn

đề đụng độ về mã nguồn khi có nhiều lập trình viên cùng làm việc chung trên một

project tại một thời điểm.

Ngoài ra, chương trình có thể tích hợp với các sản phẩm khác của công ty để

tạo thành một hệ thống quản lý cấu hình riêng theo qui trình do Seapine đề nghị cho

khách hàng sử dụng sản phẩm của họ.

5.3.2 Cấu trúc của chương trình

Surround SCM bao gồm 2 phần chính:

Server:

• Seapine License Server

• Seapine License Server Admin

• Surround SCM Server

Client:

• Surround SCM Client

• Surround SCM Analyse Utilities

Seapine License Server: đây chỉ đơn giản công cụ dùng để Seapine kiểm tra

bản quyền sử dụng của khách hàng. Seapine đòi hỏi người dùng phải chạy Seapine

License Server song song với Surround SCM Server để kiểm tra quyền sử dụng hệ

thống mỗi khi Surround Client kết nối đến server.

Seapine License Server Admin: đây là công cụ hỗ trợ cho người quản trị hệ

thống bao gồm:

• Quản lý license đăng ký sử dụng chương trình.

• Quản trị người dùng: Cho phép thêm, hủy bỏ, phân quyền sử dụng cho mỗi

user.

• Xem thông tin được ghi nhận trên server: các thông tin về vịêc kết nối đến

hệ thống hoặc các lỗi xảy ra trong quá trình sử dụng được Server ghi nhận

lại.

Trang 83

Chương 5 - Các công cụ hỗ trợ quản lý cấu hình

• Thiết lập những tùy chọn cho server: thiết các thông số liên quan đến việc

kết nối đến server: cổng kết nối, thời gian, các loại lỗi cần ghi nhận lại, thời

gian hết hạn của mật khẩu, mã hóa thông điệp khi truyền đi trong mạng ...

Surround SCM Server: là công cụ để quản lý cơ sở dữ liệu của SCM, lắng

nghe các kết nối và yêu cầu truy cập dữ liệu từ phía client đến server.

Surround SCM Client: là phần chính của SCM giúp các nhà phát triển thao

tác trên tập tin, dữ liệu được phép sử dụng (được lưu trữ trên cơ sở dữ liệu của

SCM). Cung cấp cho người dùng rất nhiều thao tác để truy cập hệ thống: check in,

check out, get ...

5.4 CVS và CVSNT

5.4.1 Mục đích

CVSNT được phát triển dựa trên công cụ mã nguồn mở có sẵn là CVS được

phát triển bởi Brian Berliner. CVSNT được phát triển để tạo ra một Server cho CVS

chạy chủ yếu trên hệ điều hành Windows NT. Vì CVS Server được thiết lập để chạy

chủ yếu trên hệ điều hành thuộc họ UNIX.

CVSNT cung cấp cho người dùng một giao diện quản trị Server bằng đồ họa

thuận tiện. Ở chế độ dòng lệnh, chương trình còn cung cấp thêm một vài lệnh bổ

xung mà CVS chuẩn không có liên quan đến việc quản trị hệ thống như: thiết lập

chế độ kết nối, thiết lập quyền truy cập cho thư mục trong kho chứa.

Cvs là một hệ thống quản lý phiên bản khá nổi tiếng trong cộng đồng mã

nguồn mở. Với công cụ này, người dùng có thể ghi nhận lại lịch sử của tập tin mã

nguồn. Giống như các chương trình quản lý mã nguồn khác, cvs cũng hỗ trợ việc

phát triển phần mềm theo nhóm hoặc phân nhánh hệ thống đang phát triển thành

nhiều nhánh khác nhau phục vụ cho những yêu cầu riêng biệt.

5.4.2 Cấu trúc của CVSNT

CVSNT có 3 chương trình chính thường được sử dụng là:

Trang 84

Chương 5 - Các công cụ hỗ trợ quản lý cấu hình

• cvsservice.exe

• cvslock.exe

• cvs.exe

cvsservice.exe & cvslock : là 2 chương trình chạy dứơi hệ thống để cung cấp

giao diện lệnh liên quan đến việc nhận kết nối từ client và quản việc truy xuất lý

kho chứa được lưu trữ trên server.

cvs.exe: còn được gọi là cvs client dùng để kết nối và tương tác với server và

truy cập kho chứa trên server.

Trang 85

Chương 6 - Ứng dụng minh họa “System Version Management”

Chương 6 Ứng dụng minh họa “System Version

Management”

6.1 Phân tích hiện trạng phát triển phần mềm tại T3H

T3H phát triển phần mềm theo quy trình thác nước bao gồm các giai đoạn sau:

• Khảo sát hiện trạng – xác định yêu cầu

• Lập giải pháp khả thi

• Phân tích

• Thiết kế

• Coding

• Kiểm thử

• Triển khai và bảo trì

Quy trình được minh hoạ qua sơ đồ

Trang 86

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-1 Qui trình phát triển phần mềm của T3H

Trang 87

Chương 6 - Ứng dụng minh họa “System Version Management”

MÔ TẢ CÁC GIAI ĐOẠN TRONG QUY TRÌNH PHÁT TRIỂN PHẦN MỀM

Giai Lập giải pháp Khảo sát – phân tích Thiết kế phần mềm Xây dựng Kiểm tra và

đoạn khả thi phần mềm thử nghiệm nội bộ

Tài liệu khảo − Tài liệu giải pháp − Tài liệu khảo sát phân − Tài − Tài liệu khảo sát

liệu khả thi tích sát phân tích phân tích

đầu − Tài liệu thiết kế − Tài liệu thiết kế

vào phần mềm phần mềm

− Prototype − Chương trình

chưong trình

1.Thiết kế kiến trúc 1.Thiết kế chung 1.Thiết kế kịch bản Mô tả − Khảo sát khả thi − Khảo sát chi tiết

phần mềm kỹ thuật: kiểm tra công − Mô tả và phân − Mô tả và phân tích

2.Thiết kế dữ liệu mức 2.Kiểm tra từng chức việc dùng − Biến tích hiện trạng : hiện trạng (chi tiết

vật lý. năng: cụ thể chung chú trọng đến hơn Giải pháp khả

3.Thiết kế chiến lược: của − Kỹ thuật tính khả thi của thi) : − Thư viện hàm:

giai − Các quy ước chung quy trình nghiệp các hàm dùng − Nghiệp vụ − Quy trình nghiệp vụ

đoạn vụ sẽ được tin chung, các hàm 3.Kiểm tra tích hợp − Cơ chế phát sinh khoá − Sơ đồ tổ chức xử lý

học hoá. hệ thống 4.Chỉnh sửa các lỗi

Trang 88

Chương 6 - Ứng dụng minh họa “System Version Management”

của chương trình lớp đối − Xác định yêu − Mối liên quan với hệ − Kiểm tra RBTV − Các

5.Thủ nghiệm cầu nghiệp vụ thống khác tượng (hoặc − Xử lý và thông báo

chuyển đổi từ dữ liệu màn hình) cơ sở lỗi − Xác định yêu − Phân tích sơ bộ

cũ 2.Thiết kế chi tiết cầu kỹ thuật − Mô hình dữ liệu sơ − Sao lưu và phục hồi

6.Lập tài liệu hướng chức năng bộ dữ liệu − Đề xuất giải

dẫn 3.Cài đặt CSDL pháp thực hiện − Yêu cầu nghiệp vụ − Bảo mật

4.Lập trình và trúc kỹ − Kiến − Yêu cầu hệ thống − Truyền (gửi/nhận) dữ

kiểm thử cục bộ thuật liệu − Yêu cầu giao diện

4.Thiết kế chức năng: − Vấn đề chuyển − Yêu cầu sao lưu

đổi, cập nhật dữ − Sơ đồ màn hình − Yêu cầu bảo mật

liệu cũ − Màn hình chính và hệ cầu đường − Yêu

− Kinh phí thống thực đơn truyền (gửi/nhận) dữ

− Thời gian thực − Màn hình liệu

hiện − Báo biểu − Yêu cầu về chuyển

thảo − Thương đổi, cập nhật dữ liệu toán xử lý − Thuật

−

hợp đồng cũ chính trên các màn

hình và báo biểu − Tập hợp các tài liệu

Trang 89

Chương 6 - Ứng dụng minh họa “System Version Management”

đã thu thập từ quá 5.Xây dựng prototype

trình khảo sát chương trình

Mô tả − Lập kế hoạch và theo dõi tiến độ

công − Quản lý cấu hình

việc − Xem xét và duyệt kết qủa công việc

chung − Tập huấn, chuyển giao kết qủa công việc

Kết liệu thiết kế − Tài liệu giải − Tài liệu khảo sát phân tích − Tài − Tài liệu Xây dựng − Tài liệu Kết

qủa pháp khả thi phần mềm phần mềm qủa

đầu chương tra − Hợp đồng − Prototype − Script phát sinh − Kiểm

ra đã ký trình CSDL chương trình

liệu − Chương trình − Tài

hướng dẫn

− Chương

trình đã kiểm

tra

Trang 90

Chương 6 - Ứng dụng minh họa “System Version Management”

• Các vai trò tham gia trong một quy trình phát triển phần mềm

NVPhân tích thiết kế - Quản trị hệ thống : hoạt động chủ yếu trong giai

đoạn lập giải pháp khả thi & khảo sát phân tích, các hồ sơ, tài liệu cuối cùng được

lưu trữ chủ yếu là văn bản giấy, nếu có lưu trữ trên máy thì cũng lưu trữ trên máy

của nhân viên phụ trách.. Sau khi kết thúc quá trình khảo sát, nhân viên ghi nhận

các yêu cầu từ khách hàng, lưu lại dưới dạng document. Khi có sửa đổi thì ghi nhận

lại ngay trên document đó.

NV Phân tích thiết kế : Khảo sát phân tích, thiết kế phần mềm lưu lại dưới

dạng các document, không theo chuẩn nhất định và cũng được sửa chồng khi có sự

thay đổi. Việc chuyển giao sang giai đoạn khác được thực hiện thông qua việc ký

nhận văn bản.

NV Lập trình : chịu trách nhiệm lập trình, chỉnh sửa code, đưa ra các release.

Mỗi nhóm lập trình sẽ được phân công từng module cụ thể. Quản lý các phiên bản

bằng Visual Source Safe. Khi source code thay đổi sẽ phát sinh 1 phiên bản mới,

tuy nhiên nó không thể hiện được sự thay đổi này ảnh hưởng đến những module

nào. Việc phân công coding cũng được thực hiện bằng tay.

NV Kiểm tra : Sau khi 1 module được coding xong hay đến 1 thời điểm quy

định, chương trình được test bởi nhóm NVKiểm tra. Việc kiểm tra được thực hiện

trên giấy. Khi phát hiện lỗi, nhân viên kiểm tra ghi nhận lại lỗi, và thực hiện lặp lại

cho đến hết module. Sau khi test xong, 1 module, bảng tường tình lỗi sẽ được gởi

đến người chịu trách nhiệm đánh giá lỗi, thường là quản lý dự án. Nếu là lỗi có thể

sửa sẽ đựơc xác nhận và chuyển giao cho bộ phận lập trình. Nếu lỗi có thể bỏ qua,

người quản lý dự án sẽ xác nhận và kết thúc việc test. (xem chi tiết mô hình bên

dưới)

NV quản lý đề án : là người có chức vụ cao nhất trong quy trình phát triển

phần mềm, quản lý toàn bộ các thành viên, chịu trách nhiệm phân công, lên kế

hoạch, theo dõi tiến độ thực hiện.

Trưởng dự án : người chịu trách nhiệm về quản lý dự án đó và ký kết hợp

đồng với phía khách hàng.

Trang 91

Chương 6 - Ứng dụng minh họa “System Version Management”

NV Quản lý cấu hình : chịu trách nhiệm về việc tổ chức quản lý những tài

liệu có liên quan đến đề án đang thực hiện như: quản lý các thành phần của từng

phiên bản có trong đề án, tạo các phiên bản test và phiên bản giao cho khách hàng,

đóng gói sản phẩm ...

NV Quản lý kiểm thử : Chịu trách nhiệm về việc lên kế họach kiểm thử, cho

từng giai đọan của đề án, đánh giá kết quả của việc kiểm thử. Và cùng với nhân viên

quản lý đề án, trưởng dự án quyết định khi nào thì ngưng việc kiểm thử trong

trường hợp chương trình vẫn còn lỗi nhưng những lỗi đó không nghiêm trọng, có

Quaûn lyù döï aùn

Tröôûng döï aùn

NV Quaûn lyù caáu hình

NV Quaûn lyù kieåm thöû

NV kieåm thöû

NV Quaûn trò heä thoáng

NV Phaân tích thieát keá

NV laäp trình

NV huaán luyeän

thể chấp nhận để giao cho khách hàng vì thời hạn giao đã gần đến ...

Hình 6-2 Sơ đồ phân cấp vai trò của nhân viên trong hệ thống

Qui trình quản lý cấu hình:

Hiện tại công việc tổ chức quản lý cấu hình của phòng phát triển phần mềm

(PPTPM) hầu như là không có và cũng ít được lưu tâm đến trong quá trình thực

hiện một đề án. Việc lưu trữ cấu hình của một phần mềm – cụ thể là cây cấu trúc

của một đề án phần mềm – được tổ chức theo chuẩn của tổ chức tập tin & thư mục.

PPTPM sử dụng một server (tạm gọi là File System) để lưu trữ toàn bộ hồ sơ (hồ sơ

phân tích, thiết kế, mã ngùôn) của từng đồ án trên đó. Các hồ sơ này được phân loại

theo loại tài liệu hoặc theo phân hệ tùy thuộc vào qui mô của đề án phần mềm.

Vd: Với một đề án nhỏ thì cây cấu hình được tổ chức theo loại tài liệu:

Trang 92

Đề án XYZ

Documents

Release

Source Code

Form

Report

Script

Help Document

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-3 Cây phân cấp theo cấu trúc

Đối với đề án lớn, như những đề án làm cho các công ty hoặc các tổ chức hành

chánh nhà nước có liên quan đến nhiều phòng ban khác nhau thì sẽ tổ chức theo các

Đề án XYZ

Phòng kế tóan

Phòng bán hàng

Phòng sản xuất

Form

Report

Script

Kho hàng

phòng ban, mỗi phòng ban tương ứng với một phân hệ trong chương trình:

Hình 6-4 Cây phân cấp theo phân hệ / kiến trúc

Trong quá trình thực hiện đề án, các lập trình viên không lấy tập tin trực tiếp

trên thư mục của server mà thông qua chương trình Visual Source Safe (VSS). Và

thực hiện việc cập nhật của mình thông qua chương trình này. Tuy nhiên mỗi lần

lấy tập tin ra và cập nhật lại nhân viên lập trình ít khi ghi chú lại mục đích của việc

lấy ra hoặc cập nhật lại.

Trang 93

Chương 6 - Ứng dụng minh họa “System Version Management”

Ngoài ra để rút ngắn thời gian thực hiện đề án, mỗi khi hoàn tất đựơc một

phân hệ nào của đề án hoặc một nhóm các chức năng của chương trình thì sẽ có

nhân viên tiến hành việc lấy phân hệ hoặc nhóm chức năng này ra biên dịch thành

một phiên bản để tiến hành kiểm thử nội bộ hoặc đem đi tham khảo ý kiến của

khách hàng. Sau khi hoàn thiện đựơc những phân hệ này thì các nhân viên lập trình

lại tiếp tục việc lập trình cho đến khi hoàn thành toàn bộ sản phẩm mà không có sự

lưu vết lại những phiên bản kiểm thử này.

Với mỗi một đề án phần mềm thì sản phẩm giao cho khách hàng là sản phần

cuối cùng sau khi hoàn chỉnh phần mềm. Nên việc xác định phiên bản để giao cho

khách hàng thường là phiên bản 1.0.

Về sau, Khi khách hàng có yêu cầu thay đổi về chương trình hoặc có nhận một

đề án tương tự, PPTPM vẫn tiến hành việc phân tích lại từ đầu và tạo một cây cấu

hình mới cho đề án phần mềm đó. Nếu có tận dụng lại thì cũng tận dụng lại những

phân hệ nào không thay đổi mà thôi. Tuy nhiên việc này thường ít xảy ra sau khi đề

án phần mềm đã ngưng.

Trang 94

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-5 Sơ đồ hoạt động của hệ thống hiện tại

6.2 Đặc tả yêu cầu của hệ thống mới

Đối với lập trình viên hệ thống mới không có gì thay đổi nhiều ngoài một số

qui định về việc truy cập hệ thống. Còn đối với người quản lý cấu hình, hệ thống

mới có thêm những công cụ nhằm tiện lợi hơn cho việc quản lý các release test,

release giao cho khách hàng, lưu trữ những thông tin về cầu hình cho từng phiên

bản của sản phẩm.

Khi có bản phân tích thiết kế chi tiết của phần phềm, người quản lý cấu hình

sẽ lên khung của project (gồm các thư mục chứa các phân hệ, các file của phân hệ)

và đưa lên server. Chương trình sẽ lưu trữ khung project này dưới dạng cây thư

mục.

Sau đó, mỗi phân hệ sẽ được giao cho các nhân viên lập trình để code.

Trang 95

Chương 6 - Ứng dụng minh họa “System Version Management”

Nhân viên lập trình sẽ check out file ra để cập nhật . Sau khi cập nhật xong,

nhân viên lập trình sẽ check in file trở lại. Hệ thống sẽ ghi nhận lại việc check in/

check out như:

• người check in/ check out

• thời gian check in/ check out

• file bị check in/ check out

• version của file tăng lên một.

Đồng thời, để dễ theo dõi sự ảnh hưởng của các phân hê, file, project với nhau,

người nhân viên quản lý cấu hình sẽ thiết lập mối quan hệ ảnh hưởng giữa các phân

hệ, file, project với nhau. Hệ thống sẽ ghi nhận lại mối ảnh hưởng này. Khi cần,

người trưởng đề án (người phân tích thiết kế) có thể dựa vào mối quan hệ ảnh

hưởng này để theo dõi sự thay đổi trong đề án khi một phân hệ, một file bị thay đổi

(do trong quá trình test phát hiện lỗi hoặc do khách hàng thay đổi yêu cầu).

Khi đã xong một hoặc nhiều phân hệ, các trưởng đề án (người quản lý cấu

hình) sẽ quyết định có tạo release trên các phân hệ đó hay không. Việc tạo release

này dùng cho quá trình test hoặc giao cho khách hàng. Hệ thống sẽ ghi nhận nội

dung của release này gồm:

• Các phân hệ bên trong release

• Các thư mục

• File

• Version của release

• Ngày tạo release

• Lý do tạo release

Yêu cầu cụ thể cho phần này:

Yêu cầu lưu trữ:

• Lưu trữ thông tin của project/ release/ phân hệ/ file

• Lưu trữ mối quan hệ của project/ release/ phân hệ/ file dưới dạng cây thư

mục

• Lưu trữ mối ảnh hưởng giữa các version file

Trang 96

Chương 6 - Ứng dụng minh họa “System Version Management”

Yêu cầu chức năng:

• Tạo các release

• Thông báo mối quan hệ ảnh hưởng khi một phân hệ/ file bị thay đổi

• Lưu vết các version của file/ phân hệ/ release.

Yêu cầu hệ thống:

• Chức năng check in/ check out

• Chức năng khoá file khi có người check out file

• Chức năng phân quyền

• Chức năng đăng nhập

• Hệ thống phải cho phép nhìn 1 đề án phần mềm theo 2 cách khác nhau:

+ Theo cấu trúc: phân cấp, giống như cấu trúc của cây thư mục được tổ

chức lưu trữ trên dĩa cứng.

+ Theo kiến trúc: của phần mềm, theo cách nhìn này thì cũng những

module & tập tin như cách tổ chức cấu trúc nhưng cho phép phân bố

lại theo từng phân hệ, hoặc theo dạng chức năng để thấy được phân hệ

nào đã được cài đặt và cài đặt cụ thể bởi những module nào ...

• Về trạng thái của các đối tượng cấu hình trong một đề án:

+ Check in / check out: cho biết đối tượng đang nằm trong hệ thống hay

đang được lấy ra để chỉnh sửa.

+ Nhất quán / không nhất quán: khi 2 đối tượng cấu hình có mối quan hệ

phụ thuộc với nhau. Nếu đối tượng phụ thuộc bị check out ra để chỉnh

sửa thì khi khi check in vào cần phải xác nhận lại xem 2 đối tượng đó

có còn nhất quán hay không. Mục tiêu là hạn chế bớt sai xót khi chỉnh

sửa đối tượng cấu hình.

Vd: A ∈ B. Nếu B bị check out ra để chỉnh sửa lại thì A & B có thể bị không

nhất quán với nhau. Lúc này cần phải có sự can thiệp của người quản lý cấu hình

xem xét xem những thay đổi của B có ảnh hưởng gì đến A hay không.

+ Reference (tham chiếu): trường hợp này liên quan nhiều đến thư viện

dùng chung hoặc hằng số ... Khi A tham chíêu đến B. Nếu check out A

Trang 97

Chương 6 - Ứng dụng minh họa “System Version Management”

ra để chỉnh sửa thì B sẽ có trạng thái là đang bị tham chiếu bởi 1 đối

tượng đã check out. Để khi B bị sửa đổi thì sẽ cảnh báo cho người

check out A ra biết về sự thay đổi này. Tham chiếu chỉ có phạm vi

trong 1 đề án.

+ Link: tương tự như tham chiếu nhưng có phạm vi rộng hơn là giữa 2 đề

án với nhau.

• Về cách xác định phiên bản:

+ Phiên bản do chương trình quản lý để lưu vết quá trình check in /

check out mà làm ảnh hưởng đến nội dung của module. ( theo dạng

tăng dần theo baseline).

+ Phiên bản do người quản lý cấu hình định cho module đó. Hay còn gọi

là việc gán nhãn cho module họăc đề án để ghi nhận lại mốc phát triển

của module hoặc đề án đó.

+ Mỗi một module sẽ có một phiên bản hiện hành. Để khi check out ra

người dùng có thể chọn check out phiên bản hiện hành hoặc check out

phiên bản mà họ chọn

+ Khi một module hoặc đề án được lấy ra để test thì tất cả module hoặc

đề án đó sẽ bị khóa lại và hình thành lên một phiên bản test. Và lúc đó

các nhân viên lập trình sẽ làm việc trên phiên bản test (kiểm lỗi & sửa

lỗi) cho đến khi kết thúc việc test thì sẽ cho phép đồng bộ lại với

module hoặc đồ án, trước khi test và tạo ra một phiên bản đã đựơc test

& sửa lỗi.

+ Trong quá trình phát triển có thể hình thành nhiều nhánh phát triển

khác nhau. Nhất là các thư viện lập trình. Vì vậy chương trình phải cho

phép tạo nhánh & cho người quản lý cấu hình biết nhánh đó được tạo

ra từ nhánh gốc nào. Đồng thời với việc tạo nhánh là việc trộn các

nhánh lại để cho ra một nhánh mới.

• Yêu cầu về giao diện: cho phép thực hiện dứơi 2 hình thức

Trang 98

Chương 6 - Ứng dụng minh họa “System Version Management”

+ Chế độ dòng lệnh: Viết các file thực thi đơn chỉ làm một hoặc 2 nhiệm

vụ cố định nào đó với các tham số đầu vào đựơc lấy từ dòng lệnh nhập.

Vd: checkin-out.exe chỉ thực hiện việc check in & check out module hoặc đề

án ra khỏi kho lưu trữ.

+ Chế độ giao tiếp đồ họa: tạo ra chương trình hoàn chỉnh tập hợp các

thao tác ở chế độ dòng lệnh đã xây dựng ở trên lại tạo sự tương tác tiện

lợi hơn cho người quản lý cấu hình.

6.3 Mô hình UseCase

Them/xoa de an

Them/xoa kho chua

Tao release

Phan quyen

Admin

Viewer

Xem lich su cua thuc the

Cap nhat cay phan he/ chuc nang

Get

Developer

Gan nhan cho cac thuc the

Cap nhat cau truc de an

Check i n

Thiet lap su anh huong gi ua cac VersionFile

Check out

6.4 Đặc tả usecase

6.4.1 Đặc tả UseCase : Đăng Nhập (Login)

6.4.1.1 Tóm tắt

Use case này mô tả cách một người dùng đăng nhập vào Hệ thống quản lý

Cấu hình.

Trang 99

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.1.2 Dòng sự kiện

Dòng sự kiện chính :

Người dùng chọn chức năng đăng nhập từ màn hình chính

• Hệ thống hiển thị màn hình Đăng nhập

• Hệ thống yêu cầu người dùng nhập UserName và Password

• Người dùng nhấn nút đồng ý

• Hệ thống nhận thông tin từ người dùng và kiểm tra trong cơ sở dữ liệu

• Hệ thống thông báo việc đăng nhập thành công

• Hệ thống sẽ hiện ra danh sách các đề án và các vai trò tương ứng

trong từng đề án mà người dùng đang tham gia.

• Người dùng sẽ chọn đề án cùng với vai trò tương ứng để làm việc

Dòng sự kiện phụ :

Tên hoặc mật khẩu sai :

• Người dùng chọn chức năng Đăng Nhập từ màn hình chính

• Hệ thống hiển thị màn hình Đăng nhập

• Hệ thống yêu cầu người dùng nhập UserName và Password

• Hệ thống nhận thông tin từ người dùng và kiểm tra trong cơ sở dữ

liệu

• Hệ thống thông báo việc đăng nhập không thành công

6.4.1.3 Các yêu cầu đặt biệt

Không có.

6.4.1.4 Điều kiện tiên quyết

Người dùng phải được cấp một tài khỏan trên hệ thống.

6.4.1.5 Post-Conditions

Nếu use case thành công, người dùng lúc này đã đăng nhập vào hệ thống với

quyền đăng nhập. Nếu không trạng thái hệ thống không thay đổi.

Trang 100

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.1.6 Điểm mở rộng

Không có.

6.4.2 Đặc tả UseCase : Thêm/xoá kho chứa

6.4.2.1 Tóm tắt

Use case mô tả cách người dùng thêm, xoá kho chứa.

6.4.2.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn thêm, xoá, kho chứa..

Hệ thống yêu cầu người dùng chọn một trong những luồng phụ sau để

thực hiện:

- Nếu người dùng chọn “Thêm kho chứa”, luồng Thêm

kho chứa được thực hiện

- Nếu người dùng chọn “Xoá kho chứa”, luồng Xoá kho

chứa được thực hiện

Thêm kho chứa

Người dùng sẽ chọn lệnh Thêm kho chứa, đưa vào các thông tin của

kho chứa như Tên kho chứa, Thư mục làm việc của kho chứa ứng với

user đăng nhập hiện hành.. Hệ thống kiểm tra thông tin nhập vào và

thêm vào cơ sở dữ liệu.

Xoá kho chứa

Người dùng chọn kho chứa cần xoá và yêu cầu xoá.

Hệ thống nhắc nhở người đúng có thật sự muốn xoá. Nếu người dùng

đồng ý xoá, hệ thống sẽ thực hiện xoá kho chứa.

Các dòng sự kiện khác

Thao tác xoá bị hủy

Trang 101

Chương 6 - Ứng dụng minh họa “System Version Management”

Nếu trong dòng sự kiện Xoá kho chứa, người sử dụng quyết đinh

không xoá kho chứa nữa thì thao tác xoá bị hủy và Dòng sự kiện

chính được bắt đầu lại từ đầu.

6.4.2.3 Các yêu cầu đặt biệt

Không có.

6.4.2.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.2.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.2.6 Điểm mở rộng

Không có.

6.4.3 Đặc tả UseCase : Thêm/xoá đề án

6.4.3.1 Tóm tắt

Use case mô tả cách người dùng thêm, xoá đề án.

6.4.3.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn thêm, xoá, đề án.

Hệ thống yêu cầu người dùng chọn một trong những luồng phụ sau để

thực hiện:

- Nếu người dùng chọn “Thêm đề án”, luồng Thêm đề án

được thực hiện

Trang 102

Chương 6 - Ứng dụng minh họa “System Version Management”

- Nếu người dùng chọn “Xoá kho chứa”, luồng Xoá đề án

được thực hiện

Thêm đề án

Người dùng sẽ chọn lệnh thêm đề án, đưa vào các thông tin của đề án

như Tên đề án, Thư mục làm việc của đề án ứng với user đăng nhập

hiện hành.. Hệ thống kiểm tra thông tin nhập vào và thêm vào cơ sở

dữ liệu.

Xoá đề án

Người dùng chọn đề án cần xoá và yêu cầu xoá.

Hệ thống nhắc nhở người đúng có thật sự muốn xoá. Nếu người dùng

đồng ý xoá, hệ thống sẽ thực hiện xoá đề án.

Các dòng sự kiện khác

Thao tác xoá bị hủy

Nếu trong dòng sự kiện Xoá đề án, người sử dụng quyết đinh không

xoá đề án đó nữa thì thao tác xoá bị hủy và Dòng sự kiện chính được

bắt đầu lại từ đầu.

6.4.3.3 Các yêu cầu đặt biệt

Không có.

6.4.3.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.3.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.3.6 Điểm mở rộng

Không có

Trang 103

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.4 Đặc tả UseCase : Cập nhật cấu trúc đề án

6.4.4.1 Tóm tắt

Use case mô tả cách người dùng thêm, xoá, sửa cấu trúc của đề án.

6.4.4.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn thêm, xoá, sửa cấu trúc

của đề án.

Người dùng có thể thêm thư mục trong đề án, khi đó luồng Thêm

thư mục sẽ được thực hiện.

Người dùng có thể thêm file trong các thư mục thuộc đề án, khi đó

luồng Thêm file sẽ được thực hiện.

Người dùng có thể xoá thư mụctrong đề án, khi đó luồng Xoá thư

mục sẽ được thực hiện.

Người dùng có thể Xoá file trong thư mục thuộc đề án, khi đó luồng

Xoá file sẽ được thực hiện.

Thêm thư mục

Người dùng có thể tạo thư mục mới bằng cách gõ tên thư mục hoặc

attach một thư mục từ bên ngoài vào (bao gồm luôn các file bên trong

thư mục đó) bằng cách chỉ ra đường dẫn vật lý. Hệ thống ghi nhận lại

việc thêm thư mục.

Thêm file

Người dùng có thể attach một file bằng cách chỉ ra đường dẫn vật lý,

thư mục cha mà file đó thuộc về. Hệ thống ghi nhận lại việc thêm file.

Xoá thư mục

Trang 104

Chương 6 - Ứng dụng minh họa “System Version Management”

Người dùng chỉ ra thư mục cần xoá và xác nhận xoá. Hệ thống ghi

nhận lại việc xoá thư mục.

Xoá file

Người dùng chỉ ra file cần xoá và xác nhận xoá. Hệ thống ghi nhận lại

việc xoá file.

Các dòng sự kiện khác

Không tồn tại thư mục

Nếu trong Dòng sự kiện thêm thư mục, xoá thư mục mà không tồn tại

thư mục đó thì hệ thống sẽ báo lỗi.

Không tồn tại file

Nếu trong Dòng sự kiện thêm file hoặc xoá file mà không tồn tại file

đó thì hệ thống sẽ báo lỗi.

Thao tác xoá bị hủy

Nếu trong dòng sự kiện xoá thư mục hoặc xoá file, người sử dụng

quyết đinh không xoá thư mục hoặc file thì thao tác xoá bị hủy và

Dòng sự kiện chính được bắt đầu lại từ đầu.

6.4.4.3 Các yêu cầu đặt biệt

Không có.

6.4.4.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.4.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

Trang 105

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.4.6 Điểm mở rộng

Không có

6.4.5 Đặc tả UseCase : Cập nhật cây phân hệ, chức năng

6.4.5.1 Tóm tắt

Use case mô tả cách người dùng thêm, xoá, sửa cấu trúc cây phân hệ, chức

năng

6.4.5.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn thêm, xoá, sửa cấu trúc

cây phân hệ, chức năng của đề án.

Người dùng có thể thêm chức năng/ phân hệ trong đề án, khi đó

luồng Thêm chức năng/ phân hệ sẽ được thực hiện.

Người dùng có thể thêm file trong chức năng/ phân hệ của đề án, khi

đó luồng Thêm file sẽ được thực hiện.

Người dùng có thể xoá chức năng/ phân hệ trong đề án, khi đó luồng

Xoá chức năng/ phân hệ sẽ được thực hiện.

Người dùng có thể Xoá file trong chức năng/ phân hệ của đề án, khi

đó luồng Xoá file sẽ được thực hiện.

Thêm chức năng/ phân hệ

Người dùng tạo chức năng/ phân hệ mới, đặt tên chức năng/ phân hệ.

Hệ thống ghi nhận lại việc thêm thư mục.

Thêm file

File được add vào từ các file bên cấu trúc của đề án. Hệ thống ghi

nhận lại việc thêm file.

Xoá chức năng/ phân hệ

Trang 106

Chương 6 - Ứng dụng minh họa “System Version Management”

Người dùng chỉ ra thư mục cần xoá và xác nhận xoá. Hệ thống ghi

nhận lại việc xoá thư mục.

Xoá file

Người dùng chỉ ra file cần xoá và xác nhận xoá. Hệ thống ghi nhận lại

việc xoá file.

Các dòng sự kiện khác

Không tồn tại file

Nếu trong Dòng sự kiện Add file mà không tồn tại file đó bên cấu trúc

của đề án thì hệ thống sẽ báo lỗi.

Thao tác xoá bị hủy

Nếu trong dòng sự kiện xoá chức năng/ phân hệ hoặc xoá file, người

sử dụng quyết đinh không xoá thư mục hoặc file thì thao tác xoá bị

hủy và Dòng sự kiện chính được bắt đầu lại từ đầu.

6.4.5.3 Các yêu cầu đặt biệt

Không có.

6.4.5.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.5.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.5.6 Điểm mở rộng

Không có

Trang 107

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.6 Đặc tả UseCase : Tạo release

6.4.6.1 Tóm tắt

Use case mô tả cách người dùng muốn tạo ra release để dùng cho việc test

hoặc dùng để giao cho khách hàng.

6.4.6.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn tạo ra release để dùng cho

việc test hoặc dùng để giao cho khách hàng.

Người dùng chọn chức năng tạo release, đặt tên cho release.

Người dùng cập nhật cây cấu trúc của release dựa trên cây cấu trúc

của đề án.

Người dùng cập nhật chức năng/ phân hệ của release dựa vào cây

chức năng/ phân hệ của đề án.

Hệ thống sẽ ghi nhận việc tạo và cập nhật cây cấu trúc và kiến trúc

của release.

Các dòng sự kiện khác

6.4.6.3 Các yêu cầu đặt biệt

Không có.

6.4.6.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.6.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

Trang 108

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.6.6 Điểm mở rộng

Không có.

6.4.7 Đặc tả UseCase : Gán nhãn cho các thực thể

6.4.7.1 Tóm tắt

Use case mô tả cách người dùng muốn gán nhãn cho các thực thể (đề án, thư

mục, phân hệ - chức năng, versionfile)

6.4.7.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn gán nhãn cho các thực thể

để quản lý phiên bản theo ý của mình.

Người dùng chọn thực thể cần gán nhãn và chọn chức năng gán nhãn.

Nếu người dùng gán nhãn đệ quy thì chương trình sẽ gán nhãn cho

thực thể đó và gán nhãn cho các thực thể con bên trong. Nếu không,

chương trình chỉ gán nhãn cho thực thể đó.

Các dòng sự kiện khác

6.4.7.3 Các yêu cầu đặt biệt

Không có.

6.4.7.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.7.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

Trang 109

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.7.6 Điểm mở rộng

Không có.

6.4.8 Đặc tả UseCase : Phân quyền

6.4.8.1 Tóm tắt

Use case mô tả cách Admin muốn thêm, xoá thành viên, cập nhật quyền của

các thành viên trong hệ thống.

6.4.8.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi Admin muốn thêm, xoá thành viên, cập nhật

thông tin của các thành viên trong hệ thống.

Hệ thống yêu cầu người dùng thực hiện một trong những luồng phụ

- Người sử dụng chọn “Thêm thành viên”, luồng sự kiện

Thêm thành viên được thực hiện.

- Người sử dụng chọn “Xoá thành viên”, luồng sự kiện

Xoá thành viên được thực hiện

- Người sử dụng chọn “Cập nhật thông tin thành viên”,

luồng sự kiện Cập nhật thông tin thành viên được

thực hiện.

Thêm thành viên

1. Người sử dụng nhập thông tin thành viên:

- tên đang nhậpthành viên

- mật khẩu cấp cho thành viên

- quyền trong hệ thống của thành viên.

2. Hệ thống lưu lại thông tin của thành viên mới và thông báo têm

Trang 110

Chương 6 - Ứng dụng minh họa “System Version Management”

thành viên thành công.

Xoá thành viên

Người sử dụng chọn thành viên cần xoá ra khỏi hệ thống và thực hiện

xoá. Hệ thống sẽ xoá thành viên này trong hệ thống.

Cập nhật thông tin thành viên

Người sử dụng chọn thành viên cần cập nhật thông tin và cập nhật lại

các thông tin như luồng sự kiện Thêm thành viên. Hệ thống sẽ lưu trữ

lại việc cập nhật này

Các dòng sự kiện khác

Không tồn tại thành viên

Trong luồng sự kiện Xoá thành viên hoặc Cập nhật thông tin

thành viên, người dùng chọn thành viên không tồn tại trong hệ

thống, hệ thống sẽ báo lỗi. Người dùng chọn lại thành viên khác hoặc

use case kết thúc.

Thao tác xoá bị hủy

Nếu trong luồng phụ Xoá thành viên, người sử dụng quyết đinh

không xoá thành viên này nữa, thao tác xoá bị hủy và Dòng sự kiện

chính được bắt đầu lại từ đầu

6.4.8.3 Các yêu cầu đặt biệt

Không có.

6.4.8.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này.

6.4.8.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

Trang 111

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.8.6 Điểm mở rộng

Không có.

6.4.9 Đặc tả UseCase : Thiết lập ảnh hưởng giữa các versionfile

6.4.9.1 Tóm tắt

Use case mô tả cách người dùng thiết lập ảnh hưởng giữa các version file với

nhau để có thể dễ dàng theo dõi mối liên hệ một khi có sự thay đổi. Chức

năng này cho phép người dùng thiết lập mới, xoá, sửa mối quan hệ.

6.4.9.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn cập nhật lập ảnh hưởng

của một version file nào đó.

• Người dùng chọn version file cần thiết lập ảnh hưởng và chọn chức

năng thiết lập ảnh hưởng.

• Hệ thống hiện ra cho người dùng version file nào gây ảnh hưởng,

cũng như những version file bị ảnh hưởng tới version file đã chọn mà

người dùng đã thiết lập trước đó.

• Người dùng có thể thêm mới các ảnh hưởng; xoá các ảnh hưởng cũng

như sửa lại các ảnh hưởng cho phù hợp

• Hệ thống ghi nhận việc cập nhật ảnh hưởng đó xuống cơ sở dữ liệu và

thông báo kết qủa cho người sử dụng.

Không tồn tại version file mà người dùng muốn xem

Các dòng sự kiện khác

Nếu trong Dòng sự kiện chính không có version file thì hệ thống sẽ

thông báo lỗi cho người sử dụng.

6.4.9.3 Các yêu cầu đặt biệt

Không có.

Trang 112

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.9.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này

6.4.9.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.9.6 Điểm mở rộng

Không có.

6.4.10 Đặc tả UseCase : Xem lịch sử phiên bản của thực thể

6.4.10.1 Tóm tắt

Use case mô tả cách người dùng xem lịch sử phiên bản của thực thể (kho

chứa, đề án, phân hệ - chức năng, file) để tìm hiểu quá trình thay đổi của thực

thể đó..

6.4.10.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn xem lịch sử phiên bản của

một thực thể nào đó.

• Người dùng chọn thực thể muốn xem lịch sử và chọn chức năng xem

lịch sử phiên bản.

• Hệ thống sẽ tìm trên cơ sở dữ liệu lịch sử phiên bản của phân hệ/ file/

đề án đã chọn.

• Hệ thống đưa ra kết qủa cho người sử dụng về:

- Các version của thực thể

- Người chịu trách nhiệm

Trang 113

Chương 6 - Ứng dụng minh họa “System Version Management”

- Ngày tạo version

- Lý do có sự cập nhật

Không tồn tại thực thể mà người dùng muốn xem

Các dòng sự kiện khác

Nếu trong Dòng sự kiện chính không có thực thể thì hệ thống sẽ

thông báo lỗi cho người sử dụng.

6.4.10.3 Các yêu cầu đặt biệt

Không có.

6.4.10.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này

6.4.10.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.10.6 Điểm mở rộng

Không có.

6.4.11 Đặc tả UseCase : Thực hiện check in

6.4.11.1 Tóm tắt

Use case mô tả cách người dùng check in để đưa file đã cập nhật trở lại đề

án.

6.4.11.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn check in một hoặc nhiều

verison file nào đó của đề án.

Trang 114

Check in

Chương 6 - Ứng dụng minh họa “System Version Management”

• Người dùng file nào đó cần check in, chọn lý do check in.

• Hệ thống ghi nhận việc check in

Không tồn tại file mà người dùng muốn check in

Các dòng sự kiện khác

Nếu trong Dòng sự kiện check in không có version file thì hệ thống

sẽ thông báo lỗi cho người sử dụng.

6.4.11.3 Các yêu cầu đặt biệt

Không có

6.4.11.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này

6.4.11.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.11.6 Điểm mở rộng

Không có

6.4.12 Đặc tả UseCase : Thực hiện check out

6.4.12.1 Tóm tắt

Use case mô tả cách người dùng check out để lấy ra, cập nhật các versionfile.

Khi người dùng check out để lấy ra file, người dùng có thể sửa đổi file đó và

thực hiện check in để ghi nhận lại (Khi đó, verion của file sẽ tăng lên).

6.4.12.2 Dòng sự kiện

Dòng sự kiện chính

Trang 115

Chương 6 - Ứng dụng minh họa “System Version Management”

Use case này bắt đầu khi người dùng muốn check out một hoặc nhiều

file nào đó của đề án.

• Người dùng chọn version file cần check out, ghi nhận lại lý do

checkout.

• Hệ thống ghi nhận việc check out.

Không tồn tại version file mà người dùng muốn check out

Các dòng sự kiện khác

Nếu trong Dòng sự kiện check out không tồn tại version file thì hệ

thống sẽ thông báo lỗi cho người sử dụng.

6.4.12.3 Các yêu cầu đặt biệt

Không có

6.4.12.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này

6.4.12.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.12.6 Điểm mở rộng

Không có

6.4.13 Đặc tả UseCase : Get

6.4.13.1 Tóm tắt

Use case mô tả cách người dùng muốn lấy ra một version file nào đó ra thể

tham khảo.

Trang 116

Chương 6 - Ứng dụng minh họa “System Version Management”

6.4.13.2 Dòng sự kiện

Dòng sự kiện chính

Use case này bắt đầu khi người dùng muốn rút trích một version file

nào đó của đề án.

• Người dùng chọn tên file và phiên bản, thư mục để lấy versionfile

ra.

Hệ thống thực hiện lấy version file mà người dùng chọn chép vào

thư mục cần lấy file ra.

Không tồn tại version file mà người dùng muốn check out/ check in

Các dòng sự kiện khác

Nếu trong Dòng sự kiện chính không tồn tạo version file mà người

dùng chọn thì hệ thống sẽ thông báo lỗi cho người sử dụng.

6.4.13.3 Các yêu cầu đặt biệt

Không có

6.4.13.4 Điều kiện tiên quyết

Người dùng phải có quyền thực hiện chức năng này

6.4.13.5 Post-Conditions

Nếu use case thực hiện thành công, hệ thống sẽ hiển thị kết qủa cho người sử

dụng. Nếu không, hệ thống sẽ thông báo lỗi, tình trạng hệ thống không thay

đổi.

6.4.13.6 Điểm mở rộng

Không có

Trang 117

Chương 6 - Ứng dụng minh họa “System Version Management”

6.5 Thiết kế

6.5.1 Kiến trúc hệ thống

SQL Server

User

Client

CVSNT

Hệ thống được theo mô hình client server:

Hình 6-6 Kiến trúc về phần cứng hệ thống

• Client

− Sử dụng chương trình SVM + CVS để truy xuất thông tin qua mạng

• Server

− SQL Server chứa dữ liệu quan hệ và thông tin phụ cho các đối tượng cấu

hình

− CVSNT Chứa file được lưu trữ

6.5.2 Giao diện

Một số màn hình chính trong chương trình

Trang 118

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-7 Màn hình chính

Trang 119

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-8 Màn hình thiết lập mối quan hệ giữa các tập tin

Trang 120

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-9 Màn hình thiết lập kiến trúc từ cấu trúc

Hình 6-10 Màn hình xem thông tin của project, kho chứa, thư mục

Trang 121

Chương 6 - Ứng dụng minh họa “System Version Management”

Hình 6-11 Màn hình xem thông tin của tập tin và phiên bản của nó

Hình 6-12 Màn hình xem lịch sử của tập tin, thư mục, project

Trang 122

Chương 6 - Ứng dụng minh họa “System Version Management”

6.5.3 Mô hình lớp đối tượng

Action

Item

1 1

Staff

StaffWorkingDir

AbstractDir

File

Version_File

1 *

Repositor

Project

Function

* 1

Release

Dir

Hình 6-13 Mô hình lớp đối tượng

1. Item : (Abstract)

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

ID Mã số của item Chuỗi <= 20 ký tự

Name Tên của item Chuỗi <= 50 ký tự

CreatedDate Ngày giờ item Ngày giờ

được tạo

Removed Cho biết item đã bị Bool

đánh dấu xoá hay

chưa

Note Ghi chú, mô tả về Chuỗi <= 200 ký

item tự

Actions Mảng lưu các hành Mảng

động đã thực hiện

Trang 123

Chương 6 - Ứng dụng minh họa “System Version Management”

trên item

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin của item

getActions Public Lấy tất cả các hành Class

động của item từ cơ sở Error

dữ liệu

setLabel Public Đặt nhãn cho item Class

Error

rename Public Đổi tên item Class

Error

remove Public Xoá thực sự/đánh dấu Class

xoá item Error

restore Public Phục hồi item đã bị Class

đánh dấu xoá Action

Trang 124

Chương 6 - Ứng dụng minh họa “System Version Management”

2. AbstractDir (Abstract) : Item

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

WorkingDirs Mảng lưu các thư Mảng

mục làm việc

tương ứng với mỗi

nhân viên

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear public Xoá thông tin của

AbstractDir

getConstruction public Lấy từ cơ sở dữ liệu tất Class

cả các thông tin của Error

AbstractDir

getActions public Lấy tất cả các hành Class

động của AbstractDir từ Error

cơ sở dữ liệu

getWorkingDirs public Lấy từ cơ sở dữ liệu tất Class

cả các working dir của Error

AbstractDir tương ứng

với mỗi nhân viên

setLabel public Đặt nhãn cho Class

AbstractDir Error

deleteWorkingDir public Xoá working dir của 1 Class

nhân viên Error

rename public Đổi tên AbstractDir Class

Error

Trang 125

Chương 6 - Ứng dụng minh họa “System Version Management”

remove public Xoá thực sự/đánh dấu Class

xoá AbstractDir Error

restore public Phục hồi AbstractDir đã Class

bị đánh dấu xoá Error

add public Thêm 1 AbstractDir con Class

vào AbtstractDir cha Error

3. Repository : AbstractDir

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Projects Mảng lưu các đề Mảng

án thuộc kho chứa

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

Clear public Xoá thông tin của kho

chứa

getConstruction public Lấy từ cơ sở dữ liệu tất Class

cả các thông tin của kho Error

chứa

getReps public Lấy từ cơ sở dữ liệu tất Class

cả các kho chứa Error

add public Thêm 1 kho chứa mới Class

vào cơ sở dư liệu Error

setWorkingDirs public Thêm vào cơ sở dữ liệu Class

working dir của một Error

nhân viên

Trang 126

Chương 6 - Ứng dụng minh họa “System Version Management”

setLabel public Đặt nhãn cho kho chứa Class

Error

rename public Đổi tên kho chứa Class

Error

remove public Xoá thực sự/đánh dấu Class

xoá kho chứa Error

restore public Phục hồi kho chứa đã bị Class

đánh dấu xoá Error

addProject public Thêm 1 đề án mới vào Class

kho chứa Error

getProjects public Lấy tất cả các đề án Class

thuộc kho chứa Error

New public Tạo ra 1 đối tượng kho Reposit

chứa mới ory

4. Project : AbstractDir

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Parent Con trỏ trỏ tới kho Con trỏ

chứa chứa đề án

Dirs Mảng lưu các thư Mảng

mục của đề án

Functions Mảng lưu các phân Mảng

hệ/chức năng của

đề án

Releases Mảng lưu các bản Mảng

phát hành của đề

án

Trang 127

Chương 6 - Ứng dụng minh họa “System Version Management”

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear public Xoá thông tin của đề án

getConstruction public Lấy từ cơ sở dữ liệu tất Class

cả các thông tin của đề Error

án

getPrjs public Lấy từ cơ sở dữ liệu tất Class

cả các đề án bất kể Error

thuộc kho chứa nào

getSubDirs public Lấy từ cơ sở dữ liệu tất Class

cả các thư mục của đề Error

án

getSubFunctions public Lấy từ cơ sở dữ liệu tất Class

cả các phân hệ/chức Error

năng của đề án

getSubReleases public Lấy từ cơ sở dữ liệu tất Class

cả các bản phát hành Error

của đề án

addDir public Thêm 1 thư mục mới Class

vào đề án Error

addFunction public Thêm 1 phân hệ/chức Class

năng mới vào đề án Error

addRelease public Thêm 1 bản phát hành Class

mới vào đề án Error

setWorkingDirs public Thêm vào working dir Class

của một nhân viên Error

setLabel public Đặt nhãn cho đề án Class

Error

Trang 128

Chương 6 - Ứng dụng minh họa “System Version Management”

rename public Đổi tên đề án Class

Error

remove public Xoá thực sự/đánh dấu Class

xoá đề án Error

restore public Phục hồi đề án đã bị Class

đánh dấu xoá Error

New public Tạo ra 1 đối tượng đề án Project

mới

checkOutTo public Check out toàn bộ đề án Class

ra 1 thư mục nào đó Error

checkIn public Check in toàn bộ đề án Class

Error

undoCheckOut public Undo check out toàn bộ Class

đề án Error

getTo public Copy toàn bộ đề án ra 1 Class

thư mục nào đó Error

5. Dir : AbstractDir

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Project Con trỏ trỏ tới đề Con trỏ

án chứa thư mục

Parent Con trỏ trỏ tới thư Con trỏ

mục cha

Release Con trỏ trỏ tới bản Con trỏ

phát hành của đề

án có chứa thư

mục

Trang 129

Chương 6 - Ứng dụng minh họa “System Version Management”

Dirs Mảng lưu các thư Mảng

mục con

VerFiles Mảng lưu các Mảng

version file thuộc

thư mục

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear public Xoá thông tin của thư

mục

getConstruction public Lấy từ cơ sở dữ liệu tất Class

cả các thông tin của thư Error

mục

getSubDirs public Lấy từ cơ sở dữ liệu tất Class

cả các thư mục con của Error

thư mục

getSubVerFiles public Lấy từ cơ sở dữ liệu tất Class

cả các version file của Error

thư mục

addDir public Thêm 1 thư mục mới Class

vào thư mục Error

addVerFile public Thêm 1 version file mới Class Chỉ sử dụng

vào thư mục Error nếu thư mục

không thuộc

1 phiên bản

phát hành

nào của đề án

setWorkingDir public Thêm vào working dir Class

Trang 130

Chương 6 - Ứng dụng minh họa “System Version Management”

của một nhân viên Error

setLabel public Đặt nhãn cho thư mục Class

Error

rename public Đổi tên thư mục Class

Error

remove public Xoá thực sự/đánh dấu Class

xoá thư mục Error

restore public Phục hồi thư mục đã bị Class

đánh dấu xoá Error

New public Tạo ra 1 đối tượng thư Dir

mục mới

checkOutTo public Check out toàn bộ thư Class

mục ra 1 thư mục nào Error

đó

checkIn public Check in toàn bộ thư Class

mục Error

undoCheckOut public Undo check out toàn bộ Class

thư mục Error

getTo public Copy toàn bộ thư mục Class

ra 1 thư mục nào đó Error

addLinkTo public Thêm 1 version file vào Class Chỉ sử dụng

thư mục Error khi thư mục

thuộc 1 phiên

bản phát

hành của đề

án

destroyLinkTo public Xoá 1 version file khỏi Class Chỉ sử dụng

thư mục Error khi thư mục

thuộc 1 phiên

Trang 131

Chương 6 - Ứng dụng minh họa “System Version Management”

bản phát

hành của đề

án

6. Function : AbstractDir

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Project Con trỏ trỏ tới đề Con trỏ

án chứa phân

hệ/chức năng

Parent Con trỏ trỏ tới Con trỏ

phân hệ/chức năng

cha

Release Con trỏ trỏ tới bản Con trỏ

phát hành của đề

án chứa phân

hệ/chức năng

Functions Mảng lưu các phân Mảng

hệ/chức năng con

Files Mảng lưu các file Mảng

thuộc phân hệ/chứ

năng

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

Clear public Xoá thông tin của thư

mục

getConstruction public Lấy từ cơ sở dữ liệu tất Class

Trang 132

Chương 6 - Ứng dụng minh họa “System Version Management”

cả các thông tin của thư Error

mục

getSubFunctions public Lấy từ cơ sở dữ liệu tất Class

cả các phân hệ/chức Error

năng con

getSubFiles public Lấy từ cơ sở dữ liệu tất Class

cả các file của phân Error

hệ/chức năng

addFunction public Thêm 1 phân hệ/chức Class

năng con Error

addLinkTo public Thêm file mới vào phân Class

hệ/chức năng Error

setLabel public Đặt nhãn cho phân Class

hệ/chức năng Error

Rename public Đổi tên phân hệ/chức Class

năng Error

Remove public Xoá thực sự/đánh dấu Class

xoá phân hệ/chức năng Error

Restore public Phục hồi phân hệ/chức Class

năng đã bị đánh dấu xoá Error

New public Tạo ra 1 đối tượng phân Functio

hệ/chức năng mới n

destroyLinkTo public Xoá 1 file khỏi phân Class

hệ/chức năng Error

Trang 133

Chương 6 - Ứng dụng minh họa “System Version Management”

7. Release : AbstractDir

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Project Con trỏ trỏ tới đề Con trỏ

án chứa bản phát

hành

Dirs Mảng lưu các thư Mảng

mục con của bản

phát hành

Functions Mảng lưu các phân Mảng

hệ/chức năng của

bản phát hành

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin của bản

phát hành

getConstruction public Lấy từ cơ sở dữ liệu tất Class

cả các thông tin của bản Error

phát hành

getSubDirs public Lấy từ cơ sở dữ liệu tất Class

cả các thư mục của bản Error

phát hành

getSubFunctions public Lấy từ cơ sở dữ liệu tất Class

cả các phân hệ/chức Error

năng của bản phát hành

addDir public Thêm 1 thư mục mới Class

vào bản phát hành Error

Trang 134

Chương 6 - Ứng dụng minh họa “System Version Management”

addFunction public Thêm 1 phân hệ/chức Class

năng mới vào bản phát Error

hành

setLabel public Đặt nhãn cho bản phát Class

hành Error

rename public Đổi tên bản phát hành Class

Error

remove public Xoá thực sự/đánh dấu Class

xoá bản phát hành Error

restore public Phục hồi bãn phát hành Class

đã bị đánh dấu xoá Error

New public Tạo ra 1 đối tượng bản Release

phát hành mới

getTo public Copy toàn bộ bản phát Class

hành ra 1 thư mục nào Error

đó

8. File : Item

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Project Con trỏ trỏ tới đề Project

án chứa file

FileType Cho biết loại của Enum Text/Binary

file (text/binnary)

AddedDate Ngày giờ file được Ngày giờ

add vào đề án

Versions Mảng chứa các Mảng

phiên bản của file

Trang 135

Chương 6 - Ứng dụng minh họa “System Version Management”

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin của file

getVersions Public Lấy từ cơ sở dữ liệu tất Class

cả các phiên bản của file Error

setFileType Public Đặt loại cho file Class

Error

New Public Tạo ra 1 đối tượng file File

mới

9. VersionFile : Item

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Project Con trỏ trỏ tới Con trỏ

đề án chứa

phiên bản file

Parent Con trỏ trỏ tới Con trỏ

thư mục chứa

phiên bản file

Dirs Mảng lưu các Mảng

con trỏ trỏ tới con trỏ

các thư mục

thuộc bản phát

hành của đề án

có sử dụng

phiên bản file

CVSVersion Tên phiên bản Chuỗi <= 20 ký tự

của phiên bản

Trang 136

Chương 6 - Ứng dụng minh họa “System Version Management”

file

Size Kích thước Số

của phiên bản

file

Status Cho biết trạng Enum CheckIn/CheckOut/

thái của phiên Normal/Dissynchronize

bản file

CheckOutDir Cho biết phiên Chuỗi <= 200 ký tự

bản file có

đang bị check

out hay không,

nếu có thì

đang bị check

out ở thư mục

nào

AffectedBy Mảng lưu các Mảng

phiên bản file

khác gây ảnh

hưởng đến

phiên bản file

này

AffectsTo Mảng lưu các Mảng

phiên bản file

khác bị ảnh

hưởng bởi

phiên bản file

này

Trang 137

Chương 6 - Ứng dụng minh họa “System Version Management”

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear public Xoá thông tin của phiên

bản file

getActions Public Lấy từ cơ sở dữ liệu tất Class

cả hành động của phiên Error

bản file

setLabel public Đặt nhãn cho phiên bản Class

file Error

rename public Đổi tên file của phiên Class

bản Error

remove public Xoá thực sự/đánh dấu Class

xoá phiên bản file Error

restore public Phục hồi phiên bản file Class

đã bị đánh dấu xoá Error

New public Tạo ra 1 đối tượng Version

phiên bản file mới File

checkOutTo public Check out phiên bản file Class

ra 1 thư mục nào đó Error

checkIn public Check in phiên bản file Class

Error

undoCheckOut public Undo check out phiên Class

bản file Error

getTo public Copy phiên bản file ra 1 Class

thư mục nào đó Error

getRelations public Lấy từ cơ sở dữ liệu tất Class

cả các phiên bản file Error

khác có quan hệ với

Trang 138

Chương 6 - Ứng dụng minh họa “System Version Management”

phiên bản file này

addRelation public Thêm mối quan hệ với 1 Class

phiên bản file khác Error

destroyRelation public Xoá mối quan hệ với 1 Class

phiên bản file khác Error

setAccessStatus protected Cập nhật trạng thái của Class

phiên bản file Error

10. Action :

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

ID Mã số của Chuỗi <= 20 ký tự

hành động

ActionType hành Enum Add/Remove/Restore/ Loại

Rename/CheckIn/ động

CheckkOut/SetLabel

Date Ngày giờ thực Ngày giờ

hành hiện

động

Note Ghi chú, mô tả Chuỗi <= 200 ký tự

khi thực hiện

hành động

Label Nhãn đặt cho Chuỗi <= 200 ký tự Chỉ sử dụng

item khi thực khi

hiện việc ActionType

SetLabel là SetLabel

Trang 139

Chương 6 - Ứng dụng minh họa “System Version Management”

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin hành

động

11. Staff :

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

ID Mã số nhân viên Chuỗi <= 20 ký tự

FullName Họ và tên của Chuỗi <= 50 ký tự

nhân viên

UserName Tên dùng để đăng Chuỗi <= 50 ký tự

nhập vào hệ thống

của nhân viên

Password Mật khẩu dùng để Chuỗi <= 20 ký tự

đăng nhập vào hệ

thống của nhân

viên

DateOfBirth Ngày sinh của Ngày giờ

nhân viên

Email Địa chỉ mail của Chuỗi <= 50 ký tự

nhân viên

Trang 140

Chương 6 - Ứng dụng minh họa “System Version Management”

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin nhân viên

getStaffs public Lấy thông tin của tất cả Class

các nhân viên có trong Error

hệ thống

createStaff public Tạo 1 nhân viên mới Class

Error

deleteStaff public Xoá 1 nhân viên ra khỏi Class

Error hệ thống

updateStaff public Cập nhật thông tin của 1 Class

Error nhân viên

getProjectsOfStaff public Lấy tất cả các đề án mà Class

nhân viên có tham gia Error

getRolesOfStaff public Lấy các quyền của nhân Class

viên trong hệ thống Error

createStaffRole public Thêm quyền trong hệ Class

thống cho 1 nhân viên Error

deleteStaffRole public Giảm quyền của nhân Class

viên trong hệ thống Error

vào hệ thống Error

Trang 141

Chương 6 - Ứng dụng minh họa “System Version Management”

12. StaffWorkingDir :

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Staff Con trỏ trỏ tới Con trỏ

nhân viên, cho biết

thư mục làm việc

ứng với nhân viên

nào

WorkingDir Thư mục làm việc Chuỗi <= 200 ký

của 1 item ứng với tự

1 nhân viên

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

clear Public Xoá thông tin

13. Error :

Thuộc tính :

Tên Ý nghĩa Kiểu Miền giá trị Ghi chú

Error Câu thông báo lỗi Chuỗi

Hành động :

Tên hàm Phạm vi Diễn giải Kiểu Ghi chú

truy xuất trả về

add Public Thêm nội dung vào câu

thông báo lỗi

show public Hiển thị câu thông báo

lỗi

Trang 142

Chương 6 - Ứng dụng minh họa “System Version Management”

clear public Xoá câu thông báo lỗi

havingError public Xác định xem có lỗi xảy bool Nếu câu

ra hay không thông báo lỗi

rỗng =>

không có lỗi,

ngược lại thì

đã xảy ra lỗi

Trang 143

Chương 6 - Ứng dụng minh họa “System Version Management”

DIRECTORY_TYPE

FILE_INFO

6.5.4 Mô hình dữ liệu

PK ID_Directory_Type

CONSTRUCTION

FILE_TYPE

PK

ID_File

TypeName

PK ID_File_Type

PK,FK1 ID_Directory PK

ID_SubDirectory

CONSTRUCTION_FUNCTION_SUBSYSTEM

TypeName

FK1

NameFile DayAdd ID_File_Type Note

PK,FK1 ID_Directory ID_Function PK

PK,FK2 ID_Directory

VERSION_FILE

PK,FK3 ID_File PK

ID_SubItem

PK

ID_Version_File

FK1

RELATIONSHIP

TYPE_RELATIONSHIP

FK5 ID_File

PK ID_Type_Relationship

FK3

PK,FK1 ID_Version_File_Affect PK

ID_Version_File_IsAffected

CVS_Version FK2 ID_Access_Status

DirectoryName ID_Directory_Type Note DayCreate ID_Run_State Removed

TypeName

FK2

ID_Type_Relationship

CONTENT_FILES

Note DateCreate Removed SizeFile CheckOutDir

LABEL_DIRECTORY

PK,FK1 ID_Directory PK

ID_verison_File

ACTION_DIRECTORY

LABEL_VERSION_FILE

PK

ID_Label _Directory

PK

ID_Action_Directory

PK

ID_Label _Version_File

FK 1

FK4

ACCESS_STATE

FK 2

ID_Directory Label ID_Action_Directory

FK5,FK6 ID_Version_File Label ID_Action_Version_File

PK ID_Access _Status

FK3 FK1

ID_Person OnDate ID_Action_Type ID_Directory Reason

Access _Status _Name Note

ACTION_VERSION_FILE

ACTION_TYPE

PK

ID_Action_Version_File

PK ID_Action_Type

WORKING_DIRECTORY

STAFF

FK3 ID_Person

ActionName

PK ID_Person

FK1

PK,FK1 ID_Directory PK,FK2 ID_Person

OnDate ID_Version_File Reason ID_Action_Type

FK4

Working_Dir

STAFF_ROLE

PK,FK4 ID_Staff_Role

FullName Username Pass_word DateOfBirth Phone Email Address

FK3 FK2 FK1

ID_Project ID_person ID_Role

ROLE

ROLE_FUNCTION

FUNCTION_GROUP

FUNCTION_LIST

PK ID_Role

PK GroupID

PK

ID_Function

PK,FK1 ID_Function PK,FK2 ID_Role

RoleName Note

ProgramType GroupName

ID_FunctionGroup ProgramType FunctioName

FK1 GroupID

Hình 6-14 Mô hình dữ liệu của hệ thống

Trang 144

Chương 6 - Ứng dụng minh họa “System Version Management”

STT

Tên bảng

Mô tả

Loại thư mục: Project, thư mục, phân

DIRECTORY_TYPE

hệ/chức năng, release.

Lưu thông tin của thư mục nói chung

STT

Tên

Kiểu dữ liệu

Miền giá trị

Mô tả

Ghi

chú

Mã

loại

1.

ID_Directory_Type

int

Thư mục

1: Repository 2: Project 3: SubSystem_Function, 4: Directory 5: Release

Tên

loại

2.

TypeName

Nvarchar(50)

thư mục

2. DIRECTORY

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Directory

Varchar(20)

Mã của thư mục

2. DirectoryName

nvarchar(50)

Tên Thư mục

3.

ID_Directory_Type

int

Mã Loại Thư mục

4. Note

nvarchar(200)

Ghi chú

5. DayCreate

SmallDateTime

Ngày tạo thư mục

6.

ID_Run_State

int

7. Removed

bit

0,1

Trạng thái xoá tạm

hay không

Trang 147

Chương 6 - Ứng dụng minh họa “System Version Management”

3. LABEL_DIRECTORY

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Label_Directory

varchar(20)

Mã của

thư mục

được gán nhãn

2.

ID_Directory

varchar(20)

Mã thư mục được

gán nhãn

3. Label

nvarchar(50)

Nhãn do người dùng

gán

4.

ID_Action_Directory varchar(20)

Mã hành động gán

nhãn.

4. CONSTRUCTION

STT

Tên

Kiểu dữ liệu Miền giá

Mô tả

Ghi chú

trị

1.

ID_Directory

varchar(20)

Mã Thư mục

Loại thư mục

khác phân hệ/

chức năng

2.

ID_SubDirectory

varchar(20)

Mã thư mục con Loại thư mục

khác phân hệ/

chức năng

5. FUNCTION_SUBSYSTEM

STT

Tên

Kiểu dữ liệu Miền

Mô tả

Ghi chú

giá trị

1.

ID_Directory

varchar(20)

Mã

thư

mục

(project,

release,

function)

Thư mục có

2.

ID_Function

varchar(20)

Mã các phân hệ/

loại là phân hệ/

chức năng của thư

chức năng

mục

Trang 148

Chương 6 - Ứng dụng minh họa “System Version Management”

6. FILE_TYPE

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_File_Type

int

Mã loại File

1: Text

2: Binary

2. TypeName

nvarchar(50)

Tên

loại File (text,

binary)

7. FILE_INFO

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_File

Varchar(20)

Mã File

2. NameFile

nvarchar(50)

Tên File

3.

ID_File_Type

Varchar(20)

Loại File

4. Note

nvarchar(200)

Chi chú về file

5. DayAdd

SmallDateTime

Ngày thêm file vào

project

8. ACCESS_STATE

STT

Tên

Kiểu dữ liệu

Miền giá trị

Mô tả Ghi

chú

Mã

trạng

1.

ID_ Access_Status

int

1: Normal

thái

truy

2: CheckIn

cập

3: CheckOut

4: Dissynchronize

Tên trạng

2. Access_Status_Name

nvarchar(50)

thái

truy

cập

Ghi chú

3. Note

Nvarchar(200)

9. VERSION_FILE

Trang 149

Chương 6 - Ứng dụng minh họa “System Version Management”

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Version_File

varchar(20)

Mã version – File

2.

ID_File

varchar(20)

Mã File

3. CVS_Version

varchar(20)

Version của File

4.

ID_Access_Status

int

Mã

trạng

thái

truy

xuất

5. Note

nvarchar(200)

Ghi chú

6. DayCreate

smallDateTime

Ngày tạo

7. Removed

Bit

0,1

Trạng thái xoá tạm

hay không

8.

SizeFile

bigint

Kích thước file

9. CheckOutDir

Nvarchar(200)

Ghi nhận lại thư mục

checkout

của

versionfile

khi

version

file

bị

checkout

10. LABEL_VERSION_FILE

STT

Tên

Kiểu dữ liệu Miền giá

Mô tả

Ghi

trị

chú

1.

ID_Label_Version_File

Mã gán nhãn

2.

ID_Version_File

varchar(20)

Mã version

file

được gán nhãn

3. Label

nvarchar(50)

Nhãn được người

dùng gán

4.

ID_Action_Version_File varchar(20)

Mã hành động gán

nhãn

11. CONTENT_VERFILES

Trang 150

Chương 6 - Ứng dụng minh họa “System Version Management”

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi chú

1.

ID_Directory

varchar(20)

Mã

thư mục

Thư mục có

chứa các file

loại là

2.

ID_Verison_File Varchar(20)

Mã version file

chứa trong thư

mục

STT

Tên

Kiểu dữ

Miền giá trị

Mô tả

Ghi chú

liệu

varchar(20)

Mã thư mục

Thư mục có

12. FUNCTION_VERSIONFILE

ID_Directory

loại là phân

hệ/ chức

năng (bên

kiến trúc)

varchar(20)

Mã file thuộc trong

ID_File

mã thư mục ở trên

13. TYPE_RELATIONSHIP

Ghi

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

chú

1.

ID_Type_Relationship

int

1: Link

Mã loại quan hệ

2: Reference

2. TypeName

nvarchar(50)

Tên loại quan hệ

14. RELATIONSHIP

Trang 151

Chương 6 - Ứng dụng minh họa “System Version Management”

STT

Tên

Kiểu dữ

Miền giá

Mô tả

Ghi

liệu

trị

chú

1.

ID_Version_File_Affect

varchar(20)

Mã Version của

file

gây

ảnh

hưởng

2.

ID_Vesion_File_IsAffected varchar(20)

Mã Version của

file bị ảnh hưởng

3.

ID_Type_Relationship

int

Loại ảnh hưởng

giữa hai version

file này

15. STAFF

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Person

varchar(20)

Mã nhân viên

2.

FullName

nvarchar(50)

Tên nhân viên

3. Username

varchar(20)

Account dang nhập của

nhân viên

4.

Pass_word

varchar(20)

Mật khẩu của nhân viên

5. DateOfBirth

varchar(20)

Ngày sinh

6.

Phone

varchar(20)

Số điện thoại

7. Email

varchar(50)

Địa chỉ email

8. Address

nvarchar(20)

Địa chỉ liên lạc

16. FUNCTION_LIST

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Function

int

Mã các chứa năng có

trong chương

trình

SVM

Trang 152

Chương 6 - Ứng dụng minh họa “System Version Management”

2.

ID_FucntionGroup

int

Thuộc nhóm

chức

năng

nào

trong

chương trình.

3.

ProgramType

int

Dùng

cho

chương

trình nào

4.

FunctionName

nvarchar(50)

Tên chức năng trong

chương trình SVM

17. ROLE

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID _Role

varchar(20)

Mã vai trò

2. RoleName

nvarchar(50)

Tên vai trò

3. Note

Nvarchar(200)

Ghi chú

Trang 153

Chương 6 - Ứng dụng minh họa “System Version Management”

18. ROLE_FUNCTION

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Function

varchar(20)

Mã chức năng của

chương trình

2.

ID_Role

varchar(20)

Mã vai trò có quyền

thực hiện chức năng

của chương trình

19. STAFF_ROLE

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

1.

ID_Staff_Role

varchar(20)

Mã bảng Staff_Role

2.

ID_Project

varchar(20)

Mã project

3.

ID_Person

varchar(20)

Mã nhân viên

4.

ID_Role

varchar(20)

Mã vai trò

20. ACTION_TYPE

STT

Tên

Kiểu dữ liệu

Miền giá trị

Mô tả

Ghi

chú

Mã loại hoạt

1.

ID_Action_Type

int

1: Add

động

của

2: Remove

chương trình

3: SetLabel

4: CheckIn

5: CheckOut

6: Rename

7: Restore

8: UndoCheckOut

Trang 154

Chương 6 - Ứng dụng minh họa “System Version Management”

2. ActionName

nvarchar(50)

Tên hoạt động

(Label, Check

in, check out,

add,

remove,

..)

21. ACTION_DIRECTORY

STT

Tên

Kiểu dữ liệu Miền giá

Mô tả

Ghi

trị

chú

ID_Action_Directory varchar(20)

Mã

bảng

Action_Directory

ID_Person

varchar(20)

Mã người thực hiện

hành động

OnDate

smalldatetime

Ngày giờ thực hiện

hành động

ID_Action_Type

int

Loại hành động

ID_Directory

Varchar(20)

Mã thư mục bị tác

động

Reason

Nvarchar(200)

Lý do thực hiện hành

động

22. ACTION_VERSION_FILE

STT

Tên

Kiểu dữ liệu Miền

Mô tả

Ghi

giá trị

chú

1.

ID_Action_Version_File varchar(20)

Mã

bảng

Action_Version_File

2.

ID_Person

varchar(20)

Mã người thực hiện

hành động

3. OnDate

Smalldatetime

Ngày giờ thực hiện

hành động

Lý do

4. Reason

nvarchar(200)

5.

ID_Action_Type

int

Loại hành động

Trang 155

Chương 6 - Ứng dụng minh họa “System Version Management”

6.

ID_Version_File

Varchar(20)

Mã version file bị tác

động

23. WORKING_DIRECTORY

STT

Tên

Kiểu dữ

Miền giá

Mô tả

Ghi

liệu

trị

chú

1.

ID_Working_Directory varchar(20)

Mã

bảng

Working_Directory

2.

ID_Person

varchar(20)

Mã người

3. Working_Dir

Thư mục làm việc ứng

với mã người

24. FUNCTION_GROUP

STT

Tên

Kiểu dữ liệu Miền giá trị

Mô tả

Ghi

chú

Mã GroupID

1. GroupID

int

1: View

2: Activities

3: Project

4: Administrator

5: Requirement

6: Test Case

7: Bug

2.

ProgramType

int

Chương trình SVM

hay QLYC

3. GroupName

Nvarchar(50)

Tên nhóm

Trang 156

Chương 6 - Ứng dụng minh họa “System Version Management”

6.6 Mô hình thiết kế

Các lược đồ sequence diagram

: User

: Staff

: frmMainApp

: frmLogin

: frmSelectWorkingProject

: frmSystemView

: DbStaff

1: // Login

2: //ShowDialog()

3: //UserName + Password

4: // Click Login

5: Login()

6: //Login()

7: //GetListStaff()

8: //staffs

9: // Login OK

Dang nhap thanh cong

10: staff

11: //ShowDialog()

12: // Chon Project + Role

13: //Click Select

14: //Project +Role duoc chon

15: //Hien thi man hinh chinh cho user + project duoc chon

16: //SetMenuRole()

6.6.1 Đăng nhập

Trang 157

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: RepositoryController

: CVSCommand

: MainForm

: CreateDirForm

: dbRepository

: CVS

: dbAction

//select add Repository()

//formLoad()

//fill infomation()

//check the infomation(Repository)

[ If the information is valid]

//AddRepository()

//call add to CSV()

//add to CVS()

//register event (action)

6.6.2 Thêm kho chứa

: User

: ProjectController

: MainForm

: CreateDirForm

: dbProject

: CVS

: dbAction

//select add Repository()

//formLoad()

//fill infomation(Project)//check the infomation(Project)

[ If the information is valid]

//AddProject(Project)

//add to CVS()

//register event(action)

6.6.3 Thêm đề án

Trang 158

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: ViewController

: ProjectController

: ReleaseController

: DirController

: MainForm

: dbDir

: dbVersionFile

//select view mode()

//set viewmode(mode Structure)

//get Structer Of Project (mode: Structure)

//get Dirs()

//get dirs of Project (IDProject)

//get VersionFiles of dir (IDDir)

//get Release (mode: Structure)

//get Structure of Release (IDRelease)

//get VersionFiles of dir(IDDir)

6.6.4 Xem Cấu trúc của project

: User

: ViewController

: ProjectController

: ReleaseController

: MainForm

: dbFunctionSubSystem

: dbFile

: FunctionSubSystemCo...

//select view mode()

//set viewmode(mode Architecture)

//get Architecture Of Project (mode: Architecture)

//get Function subsystem()

//get Function subsystem of Project (IDProject)

//get File of function/subsytem (IDFuntion)

//get Release (mode: Architecture)

//get Architecture of Release (IDRelease)

//get File of function/subsytem (IDFuntion)

6.6.5 Xem kiến trúc của đề án

Trang 159

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: VersionFileController

: MainForm

: CheckOutForm

: CVSCommand : dbVersionFile

: CVS

: dbAction

//select Checkout form(ID_VersionFile)

//FormLoad (ID_VersionFile)

//Check out(ID_VersionFile)

//Check out (ID_VersionFile)

//CheckOut(ID_VersionFile)

//register event(action)

//Get All Related file(bool)

//Set status of Related files()

6.6.6 Check out

Trang 160

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: VersionFileController

: MainForm

: CheckOutForm

: CVSCommand : dbVersionFile

: CVS

: dbAction

//select Checkin form(ID_VersionFile)

//FormLoad (ID_VersionFile)

//Check in(ID_VersionFile)

//Check in (ID_VersionFile)

//Checkin(ID_VersionFile)

//register event(action)

//Keep Related file(bool)

//Set status of Related files()

6.6.7 Check in

Trang 161

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: MainForm

: SetLabelForm : ItemController

: dbItem

: dbAction

//select set label form(ID_Item)

//FormLoad(ID_Item)

//enter label(string)

//Set label (item)

//insert label()

//register event(action)

6.6.8 Gán nhãn cho Item

Trang 162

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: VersionFileController

: MainForm

: SetRelationshipForm

: dbVersionFile

//Select set relationship Form()

//FormLoad()

//select all versionFiles (IDProject)

//select all versionFiles (ID_Project)

//select 2 versionFiles

//set relationship (ID_VerFile, ID_VerFile)

6.6.9 Thiết lập quan hệ giữa hai versionfile

Trang 163

Chương 6 - Ứng dụng minh họa “System Version Management”

: User

: MainForm

: SetLabelForm : ItemController

: dbItem

: dbAction

//select HistoryForm(ID_Item)

//FormLoad(ID_Item)

//history(ID_Item)

//select ItemInfo(ID_Item)

//select all actions (ID_Item)

//show result()

6.6.10 Xem lịch sử của Item

Trang 164

Chương 7 - Tổng kết

Chương 7 Tổng kết

7.1 Tự đánh giá

Sau khi thực hiện đề tài, chúng em đã đạt được những kết qủa sau đây

Về lý thuyết:

• Nắm sâu thêm những kiến thức cụ thể liên quan đến quản lý cấu hình phần

mềm, những công cụ được sử dụng để quản lý cấu hình.

• Hiểu rõ thêm về qui trình phát triển phần mềm đặc biệt là qui trình phát

triển theo mô hình thác nước.

• Có cơ hội tiếp cận với một đơn vị sản xuất phần mềm và tìm hiểu công việc

sản xuất phần mềm ở T3H

Về chương trình minh họa trong luận văn.

• Chương trình minh họa trong luận văn vẫn còn nhiều điểm thiếu sót so với

một công cụ về quản lý cấu hình thương mại.

• Chương trình đã thể hiện được những tính năng có thể dùng cho hệ thống

quản lý cấu hình: thiết lập kiến trúc hệ thống, quản lý phiên bản phát hành,

quản lý sự liên hệ giữa các phiên bản với nhau.

7.2 Hướng phát triển

Dựa trên kết qủa hiện tại của luận văn chúng em nhận thấy cần phải có những

mở rộng hơn nữa cho chương trình như sau:

• Chương trình chỉ mới được hoàn thiện phía client còn phía server vẫn phải

sử dụng đến cơ sở dữ liệu SQL và chương trình quản lý sự thay đổi của tập

tin bằng CVS. Có hai hướng để phát triển chương trình như sau:

• Hướng 1: Giữ lại server SQL, nhưng mở rộng bằng cách viết thêm những

module hỗ trợ cho cho nhiều hệ thống quản lý sự thay đổi tập tin như: RCS,

SCM, Visual Source Safe. Khi đó chương trình sẽ linh động ở chỗ có thể

Trang 165

Chương 7 - Tổng kết

kết hợp với những hệ quản lý sự thay đổi của tập tin khi đem sang các công

ty có những hệ thống quản lý tập tin riêng.

• Hướng 2: Tạo một hệ thống quản lý tập tin & thông tin quan hệ giữa các tập

tin riêng không sử dụng SQL hoặc một hệ thống quản lý thay đổi tập tin

nào khác.

• Tích hợp chương trình với những môi trường phát triển phần mềm tích hợp

hoặc những môi trường phân tích thiết kế để quản lý tập tin được chặt chẽ

và tiện dụng hơn cho các nhân viên phân tích & lập trình.

• Thiết kế giao diện ứng dụng dạng web để có thể hỗ trợ cho cả phía khách

hàng để có thể cập nhật được cấu hình phần mềm mới nhất hoặc tải bản sửa

lỗi thích hợp về.

Trang 166

Tài liệu tham khảo

1. Configuration Management Principles and Practice, Addison Wesley, 0-321-

11766-2,December 30,2002

2. Capability Maturity Model® Integration (CMMI), Version 1.1, Carnegie

Mellon University, Pittsburgh, PA 15213-3890

3. Katherine E. Harvey, Summary of the SEI Workshop on Software

Configuration Management, CMU/SEI-86-TR-5 December 1986

4. Dart, Susan, Spectrum of Functionality in Configuration Management

Systems, Software Engineering Institute, 1990.

http://www.sei.cmu.edu/technology/case/scm/tech_rep/TR11_90/TOC_TR11_

90.html

5. Berczuk, Steve. "Configuration Management Patterns", 1997.

6. http://www.bell-labs.com/cgi-

user/OrgPatterns/OrgPatterns?ConfigurationManagementPatterns.

7. Peter H. Feiler, Configuration Management Models in Commercial

Environments, March 1991, CMU/SEI-91-TR-7, ESD-9-TR-7

8. Susan A. Dart, The Past, Present and Future of Configuration Management,

Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA

15213, NADC, 12 February 1993.

9. Susan Dart, Concepts in Configuration Management Systems, Software

Engineering Institute , Carnegie-Mellon University, Pittsburgh, PA. 15123-

3890 USA

10. Feiler, P.H. and Downey, G., Tool Version Management Technology: A Case

Study, CMU/SEI-90-TRSEI-90-TR-25, Software Engineering Institute,

Carnegie Mellon University, November 1990

11. Microsoft Visual Source Safe

12. Surround SCM2.0.4(Windows) của hãng SeaPine Software -

www.seapine.com

13. Chương trình CVSNT

Trang 167

Chương 7 - Tổng kết

14. www.scmlabs.com

Trang 168

Luận văn: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

HỒ NGUYỄN NGỌC PHƯƠNG – 0012076

TRIỆU NGỌC TOÀN

– 0012105

QUẢN LÝ CẤU HÌNH PHẦN MỀM

TẠI PHÒNG PHÁT TRIỂN PHẦN MỀM

QUANG TRUNG – TRUNG TÂM TIN HỌC

LUẬN VĂN CỬ NHÂN TIN HỌC

TS. TRẦN ĐAN THƯ

Th.S. NGUYỄN TRỌNG TÀI

NHẬN XÉT CỦA GIÁO VIÊN HƯỚNG DẪN

NHẬN XÉT CỦA GIÁO VIÊN PHẢN BIỆN

Lời cám ơn

Lời nói đầu

Mục Lục

Danh sách hình

Danh sách bảng

Một số khái niệm / thuật ngữ

Chương 1 Mở đầu

1.1 Quản lý cấu hình phần mềm trên thế giới và ở Việt Nam

1.2 Các công cụ hỗ trợ quản lý cấu hình hiện tại

1.3 Mục tiêu đề tài

Chương 2 Tổng quan về quản lý cấu hình phần

mềm

2.1 Khái niệm

2.2 Nguồn gốc hình thành của quản lý cấu hình

2.3 Phạm vi và nhiệm vụ của quản lý cấu hình

2.4 Các vai trò trong quản lý cấu hình phần mềm

2.5 Dữ liệu cho quản lý cấu hình

2.6 Hệ thống quản lý cấu hình phần mềm

Chương 3 Quản lý cấu hình phần mềm trong

CMM & CMMI

3.1 Mô hình trưởng thành

3.2 CMM version 1.1

3.3 Quản lý cấu hình trong CMMI

Chương 4 Vấn đề định danh, quản lý phiên bản

và các giải pháp

4.1 Đặt tên các đối tượng cấu hình

4.2 Xác định và định danh phiên bản

Chương 5 Các công cụ hỗ trợ quản lý cấu hình

5.1 Tóm tắt

5.2 Tính năng chung của Surround SCM và CVS

5.3 Surround SCM

5.4 CVS và CVSNT

Chương 6 Ứng dụng minh họa “System Version

Management”

6.1 Phân tích hiện trạng phát triển phần mềm tại T3H

Hình 6-1 Qui trình phát triển phần mềm của T3H

6.2 Đặc tả yêu cầu của hệ thống mới

6.3 Mô hình UseCase

6.4 Đặc tả usecase

Thêm đề án

Xoá đề án

Thao tác xoá bị hủy

Thêm thư mục

Thêm file

Xoá thư mục

Xoá file

Không tồn tại thư mục

Không tồn tại file

Thao tác xoá bị hủy

Thêm chức năng/ phân hệ

Thêm file

Xoá chức năng/ phân hệ

Xoá file

Không tồn tại file

Thao tác xoá bị hủy

Các dòng sự kiện khác

Các dòng sự kiện khác

Không tồn tại thành viên

Thao tác xoá bị hủy

6.5 Thiết kế

Hình 6-6 Kiến trúc về phần cứng hệ thống

Action

Item

Staff

StaffWorkingDir

AbstractDir

File

Version_File