Chapter 6:Software Configuration Management

Nhóm 6 :

Nguyễn Văn Hải

Nguyễn Thành Luân

Introduction

Chắc hẳn trong chúng ta đã ít nhất một lần gặp những tình huống như :

Một lỗi (bug) nào đó của phần mềm đang xây dựng đã tốn nhiều công sức sửa chữa,bỗng dưng xuất hiện trở lại.
Một chức năng (function) nào đó của phần mềm đã được phát triển và kiểm tra cẩn thận bỗng thất lạc hoặc biến mất một cách khó hiểu.
Một chương trình (program) đã được kiểm tra hết sức cẩn thận bỗng nhiên không chạy được nữa.
Hay một chương trình gồm nhiều đơn thể (module),mà mỗi đơn thể đó là một chức năng và các chức năng lại được chia cho nhiều lập trình viên với mỗi chức năng bao gồm nhiều tập tin mã nguồn (source code) cùng với nhiều phiên bản khác nhau.Khi tích hợp hệ thống và biên dịch,trong hàng chục tập tin source code với hàng trăm version.Làm cách nào để xác định tập tin nào hay version nào là đúng cần phải lấy để tiến hành tích hợp?

Các vấn đề trên sẽ không xảy ra nếu như trong dự án việc Quản lý cấu hình (QLCH) được thực hiện nghiêm túc và kiểm soát chặt chẽ. Nói cách khác,QLCH bao gồm các công việc về nhận dạng,tổ chức và quản lý các thay đổi đối với những sản phẩm đang được xây dựng bởi một nhóm lập trình viên,từ các sản phẩm trung gian đến các sản phẩm sau cùng.

QLCH tốt sẽ giải quyết được hàng loạt những khó khăn trong các dự án,đặc biệt là các dự án lớn :

Cập nhật đồng thời : khi 2 hay nhiều lập trình viên làm việc cách biệt nhau nhưng trên cùng một chương trình hoặc dự án,những thay đổi mà người này thực hiện có thể sẽ phá vỡ kết quả làm việc của người khác.

    Ví dụ: Sản phẩm anh A sử dụng kết quả của anh B,khi sản phẩm của anh B thay đổi có thể làm cho 
    sản phẩm của anh A chạy lỗi hoặc không chạy được.

Chia sẻ source code : Trong các hệ thống lớn,khi các chức năng chung bị thay đổi tất cả những người liên quan cần được biết về sự thay đổi đó.

Phiên bản phần mềm(release) : Hầu hết các phiên chương trinhg hoặc hệ thống lớn được phát triển với nhiều phiên bản release tiến hoá từ thấp đến cao.

Có 2 khái niệm rất cơ bản trong QLCH:

Configuration Item - CI: định danh này trong QLCH là tên gọi của các sản phẩm, sản phẩm trung gian, một tập tin (file) hoặc nhóm file, tài liệu hoặc nhóm tài liệu trong một dự án mà ta cần phải quản lý và kiểm soát.
```
  Ví dụ: Một file source code, tài liệu về yêu cầu sản phẩm, bản thiết kế v.v.
```
Baseline: một điểm “mốc” được thỏa thuận bởi những người liên quan trong một dự án, sao cho sau điểm “mốc” này, mọi thay đổi phải được thông báo tới tất cả những người có liên quan.
Lập kế hoạch QLCH (Configuration Management planning)
Thông thường, việc lập kế hoạch cho QLCH được thể hiện trong tài liệu có tên Kế hoạch quản lý cấu hình (Configuration Manegement Plan – CMP). Bản kế hoạch này thường bao gồm:
Ý nghĩa, mục đích và phạm vi áp dụng của bản kế hoạch.
Vai trò và trách nhiệm của nhóm, cá nhân trong dự án thực hiện các hoạt động khác nhau liên quan đến QLCH.
Công cụ (tool), môi trường (environment) và cơ sở hạ tầng (infrastructure).
Phương pháp định danh và thiết lập baseline trên các CI.
Quy trình xử lý và quản lý các thay đổi (change control process).
Kiểm kê và báo cáo cấu hình (configuration accounting and reporting).
Quy trình thủ tục lưu trữ và chép dự phòng (backup and archieve).

Định danh/đánh số các CI (Identification of Configuration Items)

Định danh là một trong những hoạt động nền tảng của QLCH. Mục đích của định danh là để xác định tính duy nhất của một CI, cũng như mối quan hệ của nó với các CI khác. Nó bao gồm việc mô tả tên, đánh số, đánh dấu đặc trưng, giúp nhận biết và phân biệt một CI với các CI hay thành phần khác.

Bạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tế. Ví dụ, người ta đánh số bàn trong nhà hàng nhằm giúp người phục vụ mang đúng thức ăn cho khách.

Mỗi CI phải có một số định danh duy nhất, dạng thức thường thấy là:

    Ví dụ : PRJ001_REQB_1.0.4_draft_B
    Số ID của dự án: PRJ001
    Số ID của Item : REQB
    Phiên bản: 1.0.4_draft_B

Trong một dự án, thường có rất nhiều file source code, quy tắc cơ bản là: các file cùng tạo nên một khối chức năng được gom chung thành một CI.

Kiểm soát phiên bản (Version Control)

Version control là sự kiểm soát các phiên bản (version) khác nhau của một CI (bao gồm việc định danh và sự lưu trữ CI đó).

Hiện có nhiều công cụ trên thị trường hỗ trợ cho việc kiểm soát phiên bản, một số công cụ thông dụng là: Visual Source Safe của Microsoft, ClearCase của Rational, CVS (nguồn mở).

Mỗi phiên phản sẽ có một số ID đầy đủ, và được tăng dần cho mỗi phiên bản mới.

Quản lý baseline (Baseline Management)

Cũng như Version Control, baseline có nhiều cách hiểu khác nhau,Trong thực tế thường gặp các loại baseline sau:

Chức năng (functional)
Kế hoạch (planning)
Yêu cầu (requirements)
Sản phẩm (product)
Bản phân phối (release)
Kiểm tra (test)
Môi trường hoạt động (environment)

Quản lý baseline bao gồm:

Chọn các CI cho mỗi loại baseline
Tiến hành cố định baseline tại thời điểm sau khi các thay đổi đã được chấp thuận và phê chuẩn.

Thông thường, baseline được tiến hành tại điểm kết thúc của mỗi giai đoạn hay tại các “mốc” quan trọng trong dự án.

Kiểm soát thay đổi (Change control)

Khi phát triển hoặc bảo trì một sản phẩm phần mềm, việc thay đổi yêu cầu là không thể tránh khỏi.Mục đích của change control là để kiểm soát đầy đủ tất cả các thay đổi ảnh hưởng đến việc phát triển một sản phẩm. Đôi lúc chỉ một vài yêu cầu thay đổi nhỏ của khách hàng, tất cả các chặng của quy trình phát triển phần mềm từ thiết kế, đến viết code, đến kiểm tra sản phẩm đều phải thay đổi theo.

Nếu các thay đổi này không được kiếm soát chặt chẽ sẽ dẫn đến rất nhiều sai sót.

    Ví dụ: 5 lập trình viên cùng làm trong một dự án, nhưng chỉ có 3 được thông báo về việc thay đổi thiết kế. Kết quả là khi tích hợp, hệ thống sẽ không vận hành được.

Yêu cầu trong kiểm soát thay đổi là mọi sự thay đổi phải được thông báo đến tất cả những người hoặc nhóm làm việc có liên quan.

Các bước cơ bản của kiểm soát thay đổi bao gồm:

Nghiên cứu, phân tích
Phê chuẩn hoặc không phê chuẩn
Thực hiện việc thay đổi
Kiểm tra việc thay đổi
Xác lập baseline mới

Trong kiểm soát thay đổi, ta cũng thường gặp khái niệm “nhóm kiểm soát thay đổi” gọi tắt là CCB (Change Control Board), nhóm này được thành lập trong từng dự án. CCB thông thường bao gồm:

Người QLCH (Configuration Manager)
Trưởng dự án (Project Manager)
Trưởng nhóm (Technical Lead)
Trưởng nhóm kiểm soát chất lượng (Test Lead)
Kỹ sư chất lượng (Quality Engineer)

Nhiệm vụ của CCB thường là:

Bảo đảm tất cả các thay đổi được các bộ phận liên quan nhận biết và tham gia
Xem xét, phê chuẩn hoặc phủ quyết các thay đổi trên các baseline.
Kiểm tra, xác nhận các thay đổi
Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng

Báo cáo tình trạng cấu hình (Configuration Status Accounting)

Công việc này bao gồm việc ghi nhận và báo cáo tình trạng của các CI cũng như yêu cầu thay đổi, tập hợp số liệu thống kê về CI, đặc biệt là các CI góp phần tạo nên sản phẩm.

Kết quả của công việc này được ghi nhận trong một báo cáo mang tên Configuration Status Accounting Report (CSAR). Báo cáo này thường làm rõ những điểm sau:

Liệt kê tất cả baseline và CI thành phần hoặc có liên quan.
Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi
Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh hưởng (bởi sự thay đổi đó)

Báo cáo này được làm thường xuyên và định kỳ, xuyên suốt dự án.

Auditing

Có 3 loại audit thường được thực hiện :

CSAR Audit:Thường được làm sau mỗi lần một CSAR được tạo ra, việc kiểm tra bao gồm
- Bảo đảm các baseline mới nhất được liệt kê trong CSAR
- Bảo đảm tất cả CI tạo nên một baseline được liệt kê
- Kiểm tra các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúng với các yêu cầu thay đổi để khẳng định rằng sự thay đổi trên CI là hợp lý.
Physical configuration audit (PCA): nhằm mục đích khẳng định xem những gì khách hàng yêu cầu có được hiện thực hay không. Gồm 2 việc:
- Kiểm tra lịch sử trò chuyện để phản ánh tính 2 chiều (traceability) giữa yêu cầu khách hàng và việc hiện thực code trong dự án.
- Xác định những gì sẽ được phân phối cho khách hàng (executable files, source code, tài liệu đi kèm...) có đáp ứng yêu cầu khách hàng hay không.
Functional configuration audit (FCA): nhằm mục đích khẳng định những gì khách hàng yêu cầu có được kiểm tra chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng hay không. Báo gồm:
- Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra sản phẩm.

Quản lý release (Release management)

Trong thực tế, có nhiếu định nghĩa khác nhau về khái niệm Release. Về cơ bản, chúng ta có thể hiểu: Quá trình phát triển một phần mềm thường qua nhiều lần tích hợp, kết quả của mỗi lần tích hợp là một bản Build, trong rất nhiều bản Build đó, một số bản đáp ứng một số yêu cầu đã định hoặc lập kế hoạch trước (theo yêu cầu khách hàng), sẽ được gởi cho khách hàng để kiểm tra hoặc đánh giá. Các bản build này được gọi là Release.Công việc tạo ra và phân phối các bản release được gọi là Công việc Release. Theo cách hiểu này, sản phẩm sau cùng cũng là một bản release, đôi khi được gọi là Final release.

Trong quá trình release, việc quản lý đòi hỏi phải thực hiện các công việc sau:

Baseline môi trường phát triển sản phẩm và các file, tài liệu (sẽ release).
Thực hiện báo cáo CSAR
Thực hiện các audit: PCA và FCA
Đóng gói file và tài liệu sẽ release
Xác nhận đã nhận bản release từ khách hàng

Lưu trữ và chép dự phòng (Backup & archive)

Lưu trữ và chép dự phòng là một hoạt động của QLCH và là một trong những hoạt động quan trọng phải có của sản xuất phần mềm. Nó giúp khắc phục các trường hợp rủi ro bị mất mát dữ liệu do thao tác sai, virus, hoặc sự cố phần cứng/ phần mềm. Ở khía cạnh khác, nó hỗ trợ cho hoạt động version control (đã nói ở trên) trong trường hợp ta muốn sử dụng những version khác nhau.

Lưu trữ và chép dự phòng đòi hỏi toàn bộ sản phẩm và sản phẩm trung gian của dự án phải được định kỳ chép dự phòng trên những thiết bị hoặc những nơi khác một cách an toàn.

Và khi dự án kết thúc, các hoạt động sau cần phải thực hiện:

Lưu trữ toàn bộ dữ liệu của dự án, tuân thủ quy trình lưu trữ đã được thiết lập (định nghĩa bởi dự án hoặc quy định ở cấp công ty).
Lưu trữ hoặc huỷ bỏ các tài liệu ở dạng giấy.
Dọn sạch dữ liệu hoặc thông tin của dự án vừa kết thúc, sau khi đã chép lưu trữ.