Quản lý cấu hình – Yêu cầu cơ bản trong mọi dự án phần mềm

Những ai quan tâm đến quy trình sản xuất phần mềm, chắc hẳn không ít lần gặp khái niệm về quản lý cấu hình (Configuration Management). Ta dễ dàng tìm thấy các yêu cầu về quản lý cấu hình (QLCH) một cách trực tiếp hay gián tiếp trong các bộ tiêu chuẩn hoặc mô hình quy trình sản xuất phần mềm (QTSXPM) thông dụng hiện nay như CMM/CMMI, ISO 15504 hoặc ISO 9001:2000. Trong CMM và CMMI, QLCH là yêu cầu bắt buộc ngay từ mức 2, là mức cơ bản nhất của hai mô hình này.

Thực tế, có khá nhiều định nghĩa hoặc khái niệm khác biệt về QLCH, tuy rằng chúng vẫn có những điểm chung cơ bản. Trong phạm vi bài viết, chúng tôi muốn phần nào làm sáng tỏ một số định nghĩa và thuộc tính cơ bản của QLCH trong QTSXPM.

Tại sao cần Quản lý cấu hình?

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

Các vấn đề trên sẽ không xảy ra nếu như trong dự án, việc QLCH được thực hiện nghiêm túc và kiểm soát chặt chẽ.

Ta có thể tham khảo định nghĩa ngắn gọn sau từ CMM và ISO 15504: “Mục đích của QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó.”

Nói cho dễ hiểu và gần gũi, 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 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 trong các dự án lớn:

Khi nào thì cần tiến hành QLCH? QLCH được thực hiện xuyên suốt chu kỳ sống của dự án, từ lúc bắt đầu đến khi kết thúc, thậm chí vẫn còn trong giai đoạn bảo trì sản phẩm sau dự án.

HOẠT ĐỘNG QLCH

Trước khi đi vào chi tiết, ta cần tìm hiểu 2 khái niệm rất cơ bản trong QLCH:

Một cách tổng quan, QLCH bao gồm các nhóm hoạt động như hình 2.

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:

Các điểm trong bản kế hoạch trên sẽ được giải thích rõ trong các phần tiếp sau.

Đị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.

Trong sản xuất phần mềm, một CI có thể bao gồm một hay nhiều file. Ví dụ: một module tên ExpMod có thể được coi là một CI, module này có 2 file ExpMod.h và ExpMod.c.

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 cho biết:
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)

Có nhiều định nghĩa và cách hiểu khác nhau về version control, ở đây chúng tôi chỉ muốn định nghĩa nó ở khía cạnh thông dụng, sát với bản thân cụm từ nhất.

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 đó).

Thế phiên bản là gì? một phiên bản là một thực thể mới của một CI sau khi đã qua một hoặc nhiều lần xem xét và thay đổi.

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.

Lưu ý rằng phiên bản của một CI khác với phiên bản của các file thành phần của CI đó. Trong ví dụ trên, phiên bản của CI “ExpMod” khác với phiên bản của file thành phần “ExpMod.h” và “ExpMod.c”. (Xem hình 3)

Các phiên bản quan trọng của một CI có thể được đánh dấu để nhận biết một “mốc” quan trọng trong tiến trình phát triển CI đó, phiên bản mà CI được phê duyệt hay baseline.

Quản lý baseline (Baseline Management)

Cũng như Version Control, baseline có nhiều cách hiểu khác nhau, trong phạm vi bài viết này, chúng tôi chọn ý nghĩa tương đối phổ biến. Trong thực tế thường gặp các loại baseline sau:

Quản lý baseline bao gồm:

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. Hình 4 cho thấy rõ hơn các loại và thời điểm baseline.

Đồng thời, trong quản lý baseline, vai trò và nhiệm vụ của những người thiết lập hoặc phê chuẩn baseline cũng phải được định nghĩa.

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. Xét ví dụ sau: 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:

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:

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

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. Nó trả lời những câu hỏi như: có bao nhiêu file bị ảnh hưởng khi sữa chữa một lỗi phần mềm nào đó?

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:

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

Auditing

(Audit là một thuật ngữ rất thường dùng, cho nhiều ngành nghề khác nhau, tuy nhiên trong lĩnh vực sofware, chúng tôi không tìm thấy từ tiếng Việt tương đương phản ánh đủ ý nghĩa, do vậy xin giữ nguyên thuật ngữ gốc, nó có ý nghĩa gần với “kiểm tra” và “xem xét”). Có 3 loại audit thường được thực hiện.

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:

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:

Vai trò của các thành viên trong dự án

Trong một dự án điển hình, thông thường có 4 (nhóm) chức năng sau (thường gọi tắt là role) tham gia thực hiện các hoạt động QLCH:

CM (Configuration manager)

Trưởng dự án (Project manager):

CCB (Configuration Control Board)

Bao gồm các thành viên trong dự án, và có chức năng như đã nói ở trên.

Các thành viên của dự án

Các thành viên của dự án, kể cả CM, PM và thành viên CCB, có trách nhiệm:

Lời Kết

Trên đây là vài nét hết sức cơ bản về QLCH – một lĩnh vực quan trọng và cơ bản trong phát triển và sản xuất phần mềm. Thực tế, mỗi hoạt động thành phần của QLCH đều có những chi tiết riêng phức tạp. Nếu có điều kiện, trong tương lai chúng tôi sẽ bàn sâu thêm từng hoạt động thành phần, đặc biệt ở khía cạnh kỹ thuật và áp dụng thực tế. Mọi đóng góp xin gởi về địa chỉ email: [email protected].

Ngô Văn Toàn
Công ty Global CyberSoft Vietnam

(theo PC World VN)

FPT Aptech – Hệ Thống Đào Tạo Lập Trình Viên Quốc Tế