Tài liệu quản lý cấu hình phần mềm

Các vấn đề trên chắc hẳn không xảy ra nếu như trong dự án, việc quản lý cấu hình được thực hiện nghiêm túc và kiểm soát chặt chẽ với mục đích để thiết lập và bảo đảm tính toàn vẹn của cá

LỜI CẢM ƠN

Trong quá trình học tập tại trường, em đã được quý thầy cô truyền đạt tất

cả các kiến thức nền tảng, chuyên môn thiết thực và quý giá Đó là những kiến thức cần thiết làm cơ sở nghiên cứu cho việc phát triển trong ngành công nghệ thông tin, cũng như trong công việc sau khi ra trường Trong đó đồ án tốt nghiệp là cơ hội để em có thể áp dụng, tổng kết lại những kiến thức mà em đã học Đồng thời, rút ra được những kinh nghiệm thực tế và quý giá trong suốt quá trình thực hiện đề tài

Nhờ sự chỉ bảo tận tình của thầy, các thầy cô trong khoa và bạn bè cũng như sự nỗ lực tìm tòi của bản thân, đã giúp em hoàn thành đề tài một cách thuận lợi Tuy nhiên do thông tin cập nhật và kinh nghiệm thực tế còn có phần hạn chế nên kết quả của Đề tài cũng chỉ dừng lại ở chỗ học tập và trao đổi kinh nghiệm do đó tính khả thi của Đề tài còn chưa cao Bởi vậy em mong là sẽ nhận được sự góp ý của các thầy cô cùng toàn thể các bạn để đề tài được hoàn thiện hơn

Một lần nữa em xin chân thành cảm ơn các thầy cô giáo trong khoa Công Nghệ Thông Tin đã dạy dỗ em trong những năm qua

Em xin chân thành cảm ơn thầy đã tận tình giúp đỡ, chỉ bảo và tạo điều kiện để em có thể hoàn thành Đồ án tốt nghiệp này

TPHCM, ngày …tháng…năm 2011

Sinh viên

Mục lục

Hình 6: Change request tracking system model

Hình 7: Change request lỗi

Hình 8: New Change request

Hình 9: Audit file

Hình 10: Branch và child branch

Hình 1.1: Các xử lý cấu hình nhận dạng.

Một số kí hiệu viết tắt

CM - Configuration Management

SCM – Software Configuration Management

SEP – Software Engineering Process

CI – Configuration Item

CMP – Configuration Management Plan

CCB – Configuration Control Board

CSAR – Configuration Status Accounting Report

PCA – Physical Configuration Audit

FCA – Functional Configuration Audit

SCMP – Software Configuration Management Plan

SQA – Software Quality Assurance

SCI – Software Configuration Item

SCR – Software Change Request

PM – Project Manager

SCSA – Software Configuration Status Accouting

Chương I: Mở đầu

1 Mở đầu

Những ai quan tâm tới 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 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 thông dụng hiện nay như CMM/CMMI, ISO 15504 hoặc ISO 9001:2000 Trong CMM và CMMI, quản lý cấu hình là yêu cầu bắt buộc ngay từ mức 2, là mức cơ bản của 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ề quản lý cấu hình, tuy rằng chúng vẫn có những điểm chung cơ bản

Chắc hẳn trong mỗi chúng ta khi làm các dự án về phần mềm đã ít nhất một lần gặp những tình huống như:

• Một lỗi 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 “thình lình” 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

• Một chương trình gồm nhiều đơn thể (module), mỗi đơn thể gồm nhiều chức năng, các chức năng được chia ra cho nhiều lập trình viên, mỗi chức năng bao gồm nhiều tập tin mã nguồn (source code) với nhiều phên bản (version) khác nhau Khi tích hợp hệ thống và biên dịch, trong hang chục tập tin source code với hàng trăm version, tập tin nào, version nào là đúng và cần thiết phải lấy để tiến hành tích hợp?

Các vấn đề trên chắc hẳn không xảy ra nếu như trong dự án, việc quản lý cấu hình được thực hiện nghiêm túc và kiểm soát chặt chẽ với mục đích để 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 đó

Chương II: Quản lý chất lượng phần mềm

2 Quản lý chất lượng phần mềm

Quản lý chất lượng phần mềm

Quản lý chất lượng phần mềm là vấn đề không mới nhưng theo một số đánh giá

là còn yếu của các công ty phần mềm Việt Nam Một số công ty trong nước hiện đã đạt các chuẩn quốc tế CMM/CMMI trong nâng cao năng lực và quản lý chất lượng phần mềm, song chỉ đếm được trên đầu ngón tay, và hiện cũng chỉ gói gọn trong vài công ty gia công cho thị trường nước ngoài

Lâu nay, nói đến chất lượng phần mềm, không ít người nghĩ ngay đến vấn đề là xác định xem phầm mềm đó có phát sinh lỗi hay không, có “chạy” đúng như yêu cầu hay không và cuối cùng thường quy về vai trò của hoạt động kiểm tra phần mềm (testing) như là hoạt động chịu trách nhiệm chính Với quan điểm của khách hàng, điều này có thể đúng, họ không cần quan tâm nội tình của hoạt động phát triểm phần mềm,

điều họ quan tâm là liệu sản phẩm cuối cùng giao cho họ có đúng hạn hay không, làm việc có đúng như họ muốn hay không Tuy nhiên trong thực tế thì việc kiểm tra hoạt động phần mềm là quan trọng nhưng không đủ đảm sản phẩm sẽ được hoàn thành đúng hạn và đúng yêu cầu Kiểm tra sau cùng để phát hiện lỗi là điều tất nhiên phải làm, nhưng trong nhiều trường hợp, điều đó thường quá trễ và sẽ phải mất rất nhiều thời gian để sửa chữa Để đảm bảo được hai tiêu chí đó của khách hang, đòi hỏi phải có một quy trình được thực thi xuyên suốt chu kỳ phát triển của dự án phần mềm, đó là hệ thống quản lý cấu hình phần mềm.

Một hệ thống quản lý cấu hình phần mềm thường có hai mục tiêu:

Thứ nhất: Xây dựng chất lượng cho phần mềm ngay từ giai đoạn bắt đầu Điều

này đồng nghĩa với việc bảo đảm các yêu cầu cho phần mềm từ mọi nguồn khác nhau phải được định nghĩa, diễn dạt và hiểu một cách đúng đắn, giữa người đưa ra yêu cầu

và người thực hiện yêu cầu

Thứ hai: Bảo đảm chất lượng của phần mềm xuyên suốt quá trình phát triển.

Một hệ thống quản lý chất lượng phần mềm hoàn chỉnh bao gồm rất nhiều hoạt động và bộ phận cấu thành, chúng khác nhau tùy theo từng tổ chức khi triển khai Cơ bản có mười hoạt động và yếu tố cơ bản nhất thường gặp là:

1 Các tiêu chuẩn (Standards)

2 Lập kế hoạch (Planning)

3 Xem xét, xem lại (Reviewing)

4 Kiểm tra (Testing)

5 Phân tích lỗi (Defect Analysis)

6 Quản lý cấu hình (Configuration Management)

7 Bảo mật (Security)

8 Đào tạo, huấn luyện (Education/Training)

9 Quản lý người cung cấp, thầu phụ (Vendor Management)

10 Quản lý rủi ro (Risk Management)

Quản lý cấu hình phần mềm

Quy trình xây dựng phần mềm

Cũng như mọi ngành sản xuất khác, qui trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể

xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công

ty, hay ít nhất ở cấp độ dự án Có thể nói quy trình phát triển/xây dựng phần mềm (Software Development/Engineering Process - SEP) có tính chất quyết định để tạo ra sản phẩm chất lượng tốt với chi phí thấp và năng suất cao Vậy quy trình là gì?

Quy trình có thể hiểu là phương pháp thực hiện hoặc sản xuất ra sản phẩm Tương tự như vậy quy trình xây dựng phần mềm chính là phương pháp phát triển hay sản xuất ra sản phẩm phần mềm Thông thường một quy trình bao gồm các yếu tố cơ bản:

• Thủ tục (Procedures)

• Hướng dẫn công việc (Activity Guidelines)

• Biểu mẫu (Forms/Templates)

• Danh sách kiểm định (Checklists)

• Công cụ hỗ trợ (Tools)

Với các nhóm việc chính:

• Đặc tả yêu cầu (Requirements Specification): Chỉ ra những “đòi hỏi” cho cả các yêu cầu chức năng và phi chức năng.

• Phát triển phần mềm (Development): Tạo ra phần mềm thỏa mãn các yêu cầu được chỉ ra trong “Đặc tả yêu cầu”

• Kiểm thử phần mềm (Validation/Testing): Để đảm bảo phần mềm sản xuất

ra đáp ứng những “đòi hỏi” được chỉ ra trong “Đặc tả yêu cầu”

• Thay đổi phần mềm (Evolution): Đáp ứng nhu cầu thay đổi của khách hàng.Tùy theo mô hình phát triển phần mềm, các nhóm công việc được triển khai theo những cách khác nhau Để sản xuất cùng một sản phẩm phầm mềm người ta có thể dùng các mô hình khác nhau Tuy nhiên không phải tất cả các mô hình đều thích hợp cho mọi ứng dụng

Định nghĩa quản lý cấu hình phần mềm

Một hệ thống có thể được định nghĩa là một tập hợp các thành phần tổ chức để thực hiện một chức năng cụ thể hoặc thiết lập các chức năng Cấu hình của một hệ thống là các chức năng và (hoặc) các đặc tính vật lý của phần cứng, phần mềm hoặc các phần mềm được kết hợp theo quy trình cụ thể xây dựng để phục vụ một mục đích cụ thể

Phần mềm quản lý cấu hình (SCM) là một phần mềm hỗ trợ quá trình xử

lý trong vòng đời phần mềm sẽ có lợi cho quản lý dự án, phát triển và duy trì hoạt động, các hoạt động đảm báo, và các khách hang và người sử dụng sản phầm cuối cùng

Những khái niệm về quản lý cấu hình áp dụng cho tất cả các mục phải được kiểm soát, mặc dù có một số khác biệt trong việc thực hiện giữa CM phần cứng và CM phần mềm Ta có thể tham khảo định nghĩa ngắn gọn sau từ CNN

và ISO 15504: “Mục đích của quản lý cấu hình là để thiết lập và đảm bảo tính

toàn vẹn của 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, quản lý cấu hình phần mềm 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 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 Quản lý cấu hình (CM), sau đó, là kỷ luật để xác định các cấu hình của một hệ thống tại các điểm khác biệt trong thời gian cho mục đích của hệ thống kiểm soát các thay đổi cấu hình, và duy trì sự toàn vẹn và có thể vạch ra cấu hình trong suốt chu trình sống của hệ thống Nó chính thức được định nghĩa như là “một kỷ luật áp dụng hướng kỹ thuật, hành chính và giám sát về: định nghĩa và tài liệu các đặc tính chức năng và vật chất của một cấu hình, thay đổi điều khiển cho những đặc tính, bản ghi và báo cáo thay đổi việc xử lý

và tình trạng thực hiện, xác minh việc tuân thủ quy định yêu cầu.”

Tác dụng của quản lý cấu hình phần mềm

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

• Cập nhật đồng thời: Khi hai hoặc 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ông việc của anh B, sản phẩm của anh B thay đổi có thể làm cho sản phẩm anh A không chạy được nữa

• 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 phải được biết

• Phiên bản phần mềm (release): Hầu hết các chương trình hoặc hệ thống lớn được phát triển với nhiều release tiến hóa từ thấp đến cao Trong trường hợp một release khách hàng đang dùng, release khác đang được được kiểm tra (test), và một release khác nữa đang trong quá trình phát triển, khi lỗi (bug) xảy ra, việc sửa lỗi phải đồng bộ giữa ba phần này, nếu không quản lý source code tốt, vấn đề đồng bộ rất khó thực hiện được Nếu lỗi ở realease khách hàng đang dùng, nó phải được sửa trong tất cả các release sau đó.

Khi nào quản lý cấu hình phần mềm

Khi nào thì cần thiết quản lý cấu hình phần mềm? Quản lý cấu hình phần mềm đượ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

Chương III: Quản lý cấu hình phần mềm

3 Quản lý cấu hình phần mềm

Hoạt động của quan lý cấu hình phần mềm

Trước khi đi vào chi tiết, ta cần tìm hiểu hai khái niệm cơ bản trong quản lý cấu hình phần mềm:

• Configuration Item – CI: định danh này trong quản lý cấu hình là tên gọi của 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 quản lý và kiểm soát Nói chung là những “món” được tạo ra trong một dự án mà

ta cần phải quản lý 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ế, các mô hình, phần mềm…

• 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 liên quan Một cách tổng quan quản lý cấu hình các nhóm hoạt động như hình vẽ….

Từ quan điểm của một công việc của một thay đổi, CI là “cái gì” của sự thay đổi Thay đổi một phiên bản baseline cụ thể của một mục cấu hình tạo ra một phiên bản mới của sản phẩm cùng một CI, bản thân một baseline Trong kiểm tra tác động của sự thay đổi đầu tiên ta hỏi:

- CI ảnh hưởng những gì?

- Làm thế nào có các CI bị ảnh hưởng?

Một release (bản thân một versioned thực thể) có thể bao gồm các CI Tập hợp các thay đổi cho mỗi CI sẽ xuất hiện trong các ghi chú phát hành (release notes) và các ghi chú có thể chứa các đề mục cụ thể cho từng mặt cấu hình

Cũng như tham gia vào việc thực hiện các thay đổi và trong việc quản lý của một sự thay đổi, danh sách và định nghĩa của một mục cấu hình có thể hành động như

là một từ ngữ phổ biến trên tất cả các kết nối với các nhóm sản phẩm Lựa chọn và xác định cấu hình cho một dự án cụ thể có thể được xem như bước đầu tiên trong việc phát triển một kiến trúc tổng thể từ trên xuống

Kế hoạch quản lý cấu hình (CMP)

Thông thường, việc lập kế hoạch cho quản lý cấu hình đượ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 quản lý cấu hình Định nghĩa rõ ràng ai thực hiện (perform), ai xem xét (review), ai phê duyệt (approve) trên các CI của dự án, cũng như vai trò của khách hàng, người sử dụng đầu cuối.

• Công cụ (tool), môi trường (environment) và cơ sở hạ tầng (infrastructure) Phần này mô tả các công cụ phần mềm hoặc quy trình thủ tục được sử dụng hỗ trợ quản lý cấu hình, chẳng hạn công cụ quản lý phiên bản sản phẩm (version control); mô tả vị trí các máy chủ, máy trạm, cấu hình hệ thống client-server…

• Phương pháp định danh và thiết lập baseline trên các CI

• Quy ước đặt tên trong dự án, gồm cả tên file

• Quy trình xử lý và quản lý các thay đổi (change control process)

• Chỉ định thành viên nhóm Hội đồng quản lý cấu hình (Configuration Control Board – CCB)

• Thông tin nơi lưu trữ các CI

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

Định danh là một trong những hoạt động nền tảng của quản lý cấu hình 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 định danh duy nhất, dạng thức thường là:

Ví dụ: PRJ001_REQB_1.0.4_draft_B cho biết :

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ỉ 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 bả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 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 “ghim chết” 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 Đồ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ụ: 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 “hội đồng kiểm soát thay đổi” (Change Control Board), nhóm này được thành lập từng dự án Change Control Board thông thường bao gồm:

• Người quản lý cấu hình (Configuration Manager)

• Trưởng dự án (Project Manager)

• Trưởng nhóm (Technical Lead)

• Kỹ sư chất lượng (Quanlity Engineer)

• Và những ai bị ảnh hưởng bởi các thay đổi

Nhiệm vụ của Change Control Board thường là:

• Bảo đảm tất cả các thay đổi là đượ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, 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

Kiểm kê 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:

• 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 CI đang được phát triển hoặc vừ 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 đó)

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

Audit

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, em 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 “ghi nhận” và “xem xét” 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ý

PCA (Physical Configuration Audit): Nhằm mục đích khẳng định xem

những gì khách hàng yêu cầu có được thực hiện hay không Gồm hai việc:

• Kiểm tra vết để phản ánh tính hai chiều (tracebitily) giữa yêu cầu khách hàng và việc thực hiện code trong dự án

• Xác định những gì sẽ được phân phối cho khách hàng (Executable file, source code, tài liệu đi kèm…) có đáp ứng yêu cầu khách hàng hay không?

FCA (Functional Configuration Audit): Nhằm mục đích khẳng định

những gì khách hàng yêu cầu đượ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 Gồm: Kiểm tra vết để phản ánh tính hai 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 (xem định nghĩa ở trên)

• 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 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 quản lý cấu hình 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 hủy 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ữ

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

1 Người quản lý cấu hình: CM (Configuration Manager):

• Thiết lập và bảo trì kho lưu trữ (repository) của dự án

• Phát triển và triển khai các quy trình thủ tục quản lý cấu hình phần mềm của dự án

• Thiết lập các baseline, ghi nhận các thay đổi trên các baseline

• Bảo đảm các baseline không bị thay đổi khi chưa được phê chuẩn

• Tổ chức và điều phối các cuộc họp của CCB

2 Trưởng dự án: PM (Project Manager)

• Giám sát các hoạt động quản lý cấu hình phần mềm

• Bảo đảm các yêu cầu cần thiết cho hoạt động quản lý cấu hình Ví dụ:

số giờ thành viên dự án bỏ ra cho quản lý cấu hình, công cụ hỗ trợ quản lý cấu hình…

3 Hội đồng quản lý cấu hình: 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

• Tham gia vào nhóm CCB khi có yêu cầu

Quy trình quản lý cấu hình phần mềm

SCM điều khiển sự tiến hóa và toàn vẹn của một sản phẩm bằng xác định các yếu tốt của nó, quản lý và kiểm soát sự thay đổi, xác minh, ghi lại và báo cáo về thông tin cấu hình Đứng trên quan điểm của kỹ sư phần mềm, SCM tạo điều kiện phát triển

và hoạt thay đổi các thay đổi thực thi Một SCM thực hiện thành công đòi hỏi phải lập

kế hoạch và quản lý một cách cẩn thận Điều này, đòi hỏi một sự hiểu biết về bối cảnh

tổ chức và các khó khăn đặt trên, việc thiết kế và thực hiện các quy trình SCM

Bối cảnh tổ chức

Để lập kế hoạch xử lý quản lý cấu hình cho một dự án, thì điều cần thiết

là phải hiểu bối cảnh tổ chức và các mối quan hệ giữa các yếu tố của tổ chức Quán lý cấu hình tương tác với một số hoạt động khác hoặc các yếu tố của tổ chức

Các yếu tố tổ chức chịu trách nhiệm về công nghệ phần mềm hỗ trợ quá trình có thể được cấu trúc theo những cách khác nhau Mặc dù trách nhiệm về thực hiện nhiệm vụ nhất định của quản lý cấu hình có thể được giao cho các bộ phận khác của tổ chức như các tổ chức phát triển, trách nhiệm chung cho quản

lý cấu hình thường thuộc về một yếu tố được tổ chức riêng biệt hoặc cá nhân được chỉ định.

Quản lý cấu hình có thể giao tiếp với chất lượng hoạt động của tổ chức đảm bảo về các vấn đề như quản lý bản ghi hoặc non-configuration items Trước đây, một số mục dưới sự điều khiển của quản lý cấu hình cũng có thể là các hồ sơ dự án để thuộc vào quy định của chương trình đảm bảo chất lượng của

tổ chức Quản lý non – configuration thường là trách nhiệm của hoạt động đảm bảo chất lượng, tuy nhiên, quản lý cấu hình có thể giúp đỡ về theo dõi và báo cáo về các cấu hình phần mềm rơi vào loại này

Có lẽ mối quan hệ gần gũi nhất là sự phát triển phần mềm và các tổ chức bảo trì

Hạn chế và hướng dẫn cho tiến trình SCM

Những ảnh hưởng ràng buộc, việc chỉ đạo, việc xử lý quản lý cấu hình đến từ một vài nguồn Các chính sách và thủ tục ở phía tập đoàn hay tổ chức các cấp khác có thể ảnh hưởng hay quy định thiết kế và thực thi quá trình quản lý cấu hình cho một dự án đã định Ngoài ra, hợp đồng giữa bên yêu cầu và nhà cung cấp có thể quy định ảnh hưởng đến quá trình quản lý cấu hình Ví dụ, việc kiểm tra cấu hình có thể được yêu cầu, hay nó có thể xác định rằng một số mặt hàng được đặt theo quản lý cấu hình Khi sản phẩm phần mềm được phát triển

có khả năng ảnh hưởng đến an toàn công cộng, các cơ quan bên ngoài quy định

có thể áp đặt những hạn chế Cuối cùng, việc chọn lựa xử lý vòng đời phần mềm riêng biệt cho một dự án phần mềm và công cụ được chọn để thực thi thiết kế phần mềm hiệu quả và việc thực thi của việc xử lý quản lý cấu hình phần mềm

Hướng dẫn cho việc thiết kế và thực thi một quy trình SCM cũng có thể được lấy từ “thực hành tốt nhất (best practice)”, như được phản ánh trong các tiêu chuẩn về công nghệ phần mềm do các tổ chức tiêu chuẩn khác nhau Cung

cấp nhiều lộ trình cho các tổ chức này và tiêu chuẩn của họ Best practice còn được phản ánh trong việc cải tiến quy trình và các mô hình đánh giá quá trình như các phần mềm của Engineering Institute’s Capability Maturity Model Integration (SEI/CMMI) và ISO/IEC 15504 Sofware Engineering – Process Asscessment (ISO/IEC 15504-98).

Kế hoạch SCM (Planing SCM)

Kế hoạch của một quá trình SCM cho một dự án nên được đưa ra phù hợp với bối cảnh của tổ chức, áp dụng những hạn chế, hướng dẫn thường được chấp nhận, và tính chất của dự án (ví dụ, kích thước và tới hạn) Các hoạt động chuyên ngành được kiểm soát là: Nhận dạng cấu hình phần mềm, kiểm soát cấu hình phần mềm, kiểm kê trạng thái cấu hình phần mềm, ghi nhận cấu hình phần mềm, và phần mềm quản lý người cung cấp, thầu phụ Ngoài ra, các vấn đề như

tổ chức và trách nhiệm, nguồn lực và lịch trình, lựa chọn công cụ và triển khai thực hiện, nhà bán và kiểm soát nhà thầu phụ, và điều khiển giao diện thường được xem xét Kết quả của những hoạt động lập kế hoạch được ghi lại trong một

kế hoạch quản lý cấu hình phần mềm (SCMP) mà thường phải SQA xem xét và ghi nhận

SCM tổ chức và trách nhiệm (SCM organization and responsibilities)

Để tránh nhầm lẫn về những người sẽ thực hiện được các hoạt động SCM hay các nhiệm vụ, các tổ chức có liên quan trong quá trình SCM cần được xác định rõ ràng Trách nhiệm cụ thể cho các hoạt động SCM hay các công việc cũng cần phải được giao cho các thực thể tổ chức, hoặc bởi các phần tử tổ chức Toàn bộ quyền và việc báo cáo cho SCM cũng nên được xác định, mặc dù điều này có thể được thực hiện tại giai đoạn quản lý dự án hoặc giai đoạn lập kế hoạch đảm bảo chất lượng

SCM nguồn lực và lịch trình (SCM resources and schedules)

Kế hoạch SCM xác định các nhân viên và các công cụ liên quan đến việc thực hiện các hoạt động và nhiệm vụ cho SCM Nó chỉ lập lịch trình các câu hỏi bằng cách thiết lập trình tự cần thiết của SCM và xác định các mối quan hệ của

họ với lịch trình của dự án và cột mốc quan trọng ở giai đoạn lập dự án quy hoạch quản lý Bất cứ yêu cầu đào tạo cần thiết cho việc triển khai thực hiện kế hoạch đào tạo đội ngũ nhân viên và các thành viên mới cũng được xác định

Chọn lựa công cụ và thực thi (Tool selection and implementation)

Khả năng khác nhau của các loại công cụ, và các thủ tục để họ sử dụng,

hỗ trợ các hoạt động SCM Tùy thuộc vào tình hình, khả năng các công cụ có thể được làm sẵn với một số kết hợp các công cụ hướng dẫn sử dụng, các công

cụ tự động cung cấp một khả năng SCM duy nhất, công cụ tự động tích hợp một loạt các khả năng SCM, hoặc các môi trường được tích hợp công cụ phục vụ cho nhu cầu của nhiều người tham gia trong quá trình công nghệ phần mềm Công cụ tự động hỗ trợ ngày càng trở nên quan trọng, và ngày càng khó thiết lập, như các dự án phát triển số lượng và như các dự án về môi trường trở nên phức tạp hơn Những khả năng cung cấp các công cụ hỗ trợ cho:

• Thư viện SCM

• Yêu cầu thay đổi phần mềm (SCR) và thủ tục phê duyệt

• Mã (và các công việc liên quan đến sản phẩm) và thay đổi nhiệm vụ quản lý

• Báo cáo tình trạng quản lý cấu hình và tập hợp kích thước SCM

• Ghi nhận cấu hình phần mềm

• Quản lý và theo dõi tài liệu phần mềm

• Thực hiện các phần mềm xây dựng

• Quản lý và theo dõi release và phân phối phần mềm của họ

Các công cụ được sử dụng trong các phần này cũng có thể cung cấp các phép đo cho việc cải tiến quy trình Royce miêu tả bảy biện pháp cốt lõi của giá trị trong việc quản lý quy trình công nghệ phần mềm Thông tin có sẵn từ các công cụ SCM khác nhau liên quan đến công việc của Royce và quản lý tiến độ

và các chỉ thị chất lượng của các thay đổi giao thông (Change Traffic) và ổn định (Stability), vỡ (Breakage) và tính modul (Modularity), làm việc lại (Rework), tính thích nghi (Adaptability), MTBF (Mean Time Between Failures)

và trưởng thành (Maturity) Báo cáo về những chỉ số này có thể được tổ chức lại bằng nhiều cách khác nhau, chẳng hạn như bằng mục cấu hình phần mềm (Software Configuration Item) hay bởi kiểu của thay đổi được yêu cầu (change requested)

Chúng ta có thể hình dung một khả năng lập bản đồ và các thủ tục của các công cụ để SCM hoạt động:

Hình 1: Bản đồ và thủ tục của các công cụ để SCM hoạt động.

Trong ví dụ này, các hệ thống quản lý mã hỗ trợ cho hoạt động của các thư viện phần mềm bằng cách kiểm soát truy cập vào các yếu tố thư viện, điều phối các hoạt động đa người dùng, và giúp đỡ để thi hành các thủ tục điều hành Các công cụ hỗ trợ quá trình xây dựng phần mềm và phát hành tài liệu hướng dẫn từ các yếu tố phần mềm chứa trong thư viện Công cụ cho việc quản lý các yêu cầu thay đổi phần mềm hỗ trợ các thủ tục kiểm soát thay đổi được áp dụng cho các phần mềm điều khiển Các công cụ khác có thể cung cấp việc quản lý

cơ sở dữ liệu và báo cáo năng lực quản lý, phát triển, và các hoạt động đảm bảo chất lượng Như đã đề cập ở trên, khả năng của một số loại công cụ có thể được tích hợp vào các hệ thống SCM, cái có mục đích chặt chẽ với các hoạt động của nhiều phần mềm khác

Trong kế hoạch, các kỹ sư phần mềm chọn lựa công cụ quản lý cấu hình phần mềm cho phù hợp với công việc Kế hoạch xem xét các vấn đề có thể phát

sinh trong việc thực thi các công cụ này, đặc biệt nếu một số hình thức thay đổi văn hóa là cần thiêt.

Người bán hàng (Vendor)/ Subcontractor Control.

Một dự án phần mềm có thể đạt được hoặc sử dụng các sản phẩm phần mềm được mua, chẳng hạn như trình biên dịch hay các công cụ khác Việc lập

kế hoạch SCM sẽ xem xét nếu và bằng cách nào những mục này sẽ được thực hiện dưới sự kiểm soát cấu hình (ví dụ, tích hợp vào các thư viện của dự án) và làm thế nào để việc thay đổi hoặc cập nhật sẽ được đánh giá và quản lý

Tương tự như vậy xem xét ứng dụng cho Subcontrated software Trong trường hợp này, các yêu cầu của SCM sẽ được áp dụng vào SCM của nhà thầu phụ (Subcontractor’s SCM) như một phần của hợp đồng phụ (subcontrac) và các phương tiện để giám sát việc tuân thủ cũng cần phải được thiết lập Sau đó bao gồm việc xem xét những thông tin SCM nào phải có sẵn để giám sát việc tuân thủ có hiệu quả

Giao diện điều khiển (Interface control)

Khi một mục phần mềm (software item) sẽ giao diện (interface) với một mục phần mềm hoặc mục phần cứng khác, một sự thay đổi mục này có thể ảnh hưởng đến mục kia Việc lập kế hoạch cho quá trình SCM xem xét các mục giao diện làm thế nào để xác định được và làm thế nào để thay đổi các mục được quản lý và tryền đạt Vai trò của SCM có thể là một phần của quá trình, xử lý mức hệ thống cho các đặc điểm kỹ thuật giao diện và điều khiển, có thể bao gồm chi tiết kỹ thuật giao diện, kế hoạch kiểm soát giao diện, và các văn bản giao diện điều khiển Trong trường hợp này, SCM lập kế hoạch để kiểm soát giao diện diễn ra trong bối cảnh xử lý ở mức hệ thống

Bản kế hoạch SCM (SCM Plan)

Kết quả của việc lập kế hoạch SCM cho một dự án nhất định được ghi trong một bản SCM (SCMP), một “tài liệu sống (living document)” nó phục vụ như một tài liệu tham khảo cho quá trình SCM Nó được duy trì (cập nhật và phê duyệt) một cách cần thiết trong vòng đời phần mề Thực thi SCMP, đó là việc cần thiết để phát triển chi tiết hơn, các thủ tục cấp dưới xác định các yêu cầu cụ thể như thế nào sẽ được thực hiện hoạt động từng ngày một

Hướng dẫn về việc tạo ra và duy trì một SCMP, dựa trên thông tin được sản xuất bởi các hoạt động lập kế hoạch, có sẵn từ một số nguồn, như IEEE828-

98 Tham chiếu này cung cấp các yêu cầu về thông tin được chứa trong một SCMP Nó cũng định nghĩa và mô tả sáu loại SCM thông tin để được bao gồm trong một SCMP:

• Giới thiệu (mục đích, phạm vi, điều khoản sử dụng)

• Quản lý SCM (tổ chức, trách nhiệm, chính quyền, áp dụng các chính sách, chỉ thị, và thủ tục)

• Các hoạt động SCM (cấu hình xác định, cấu hình điều khiển, vv)

• Lập biểu SCM (phối hợp với các hoạt động dự án khác)

• Tài nguyên SCM (công cụ, tài nguyên vật chất, và nguồn nhân lực)

• Bảo trì SCM

Cấu hình giám sát của phần mềm quản lý (Surveillance of SCM)

Sau khi quá trình SCM đã được triển khai thực hiện, một số mức độ giám sát có thể cần thiết để bảo rằng các quy định của SCMP được thực hiện đúng cách Có khả năng cụ thể SQA yêu cầu cho việc đảm bảo tuân thủ các quy định với quy trình quản lý cấu hình và các thủ tục được rõ ràng Điều này có thể liên

quan đến một ban thẩm định SCM đảm bảo rằng những người có trách nhiệm được giao nhiệm vụ SCM định nghĩa được chính xác nhất Đảm bảo thẩm định chất lượng phần mềm, như một phần của một hoạt động ghi nhận đúng, cũng có thể thực hiện sự giám sát này.

Việc sử dụng các công cụ SCM tích hợp với khả năng kiểm soát quá trình có thể thực hiện nhiệm vụ giám sát dễ dàng hơn Một số công cụ tạo thuận lợi cho việc tuân thủ quy trình trong khi cung cấp tính linh hoạt cho các kỹ sư phần mềm để thích ứng với các thủ tục Quá trình thi hành các công cụ khác, để các kỹ sư phần mềm với tính linh hoạt hơn Yêu cầu quan sát và mức độ linh hoạt để cung cấp cho các kỹ sư phần mềm đang cân nhắc quan trọng trong việc lựa chọn công cụ

SCM các độ đo và phép đo lường (SCM measures and measurement)

Các công cụ đo lường SCM có thể được thiết kế để cung cấp thông tin cụ thể về phát triển phần sản phẩm hoặc để cung cấp sự hiểu biết sâu sắc về các hoạt động của quá trình SCM Một mục tiêu liên quan của quá trình giám sát SCM h là để khám phá những cơ hội để cải tiến quy trình Độ đo của quy trình SCM cung cấp một phương pháp tốt để theo dõi hiệu quả hoạt động SCM trên

cơ sở liên tục Các phép đo này có ích trong đặc trưng tình trạng hiện tại của quá trình này, cũng như trong việc cung cấp một cơ sở cho việc so sánh về thời gian Phân tích các số đo có thể tìm ra những hiểu biết dẫn đến sự thay đổi và cập nhật tương ứng cho SCMP

Bộ thư viện phần mềm và các công cụ SCM khác nhau khả năng cung cấp nguồn cho thông tin rút trích về đặc tính của quá SCM (cũng như cung cấp các dự án và thông tin quản lý) Ví dụ, thông tin về thời gian cần thiết để thực hiện các loại thay đổi sẽ là hữu ích trong việc đánh giá các tiêu chí để xác định những gì của các cấp thẩm quyền tối tưu cho phép một số loại thay đổi

Việc chăm sóc phải được thực hiện để duy trì sự tập trung của các giám sát trên những hiểu biết có thể thu được từ việc đo đạc, không phải trên các phép đo chính mình.

Ghi nhận in – process của SCM (In – process audits of SCM)

Việc ghi nhận có thể được thực hiện trong xử lý công nghệ phần mềm để điều tra trạng thái hiện tại của các yếu tố cụ thể của cấu hình hoặc để đánh giá việc thực hiện các quy trình SCM Ghi nhận quá trình của SCM cung cấp một

kỹ thuật chính thức để theo dõi thêm các khía cạnh của quá trình lựa chọn và có thể được phối hợp với chức năng SQA

Nhận dạng cấu hình phần mềm (Software configuration identification)

Hoạt động nhận dạng của cấu hình phần mềm mục phải được kiểm soát, thiết lập chương trình nhận dạng cho các mục và các phiên bản của họ, và thiết lập các công

cụ và kỹ thuật được sử dụng trong việc mua và quản lý mục được điều khiển Những hoạt động này tạo cơ sở cho hoạt động SCM khác

Nhận dạng các mục để được kiểm soát (Identifying items to be controlled)

Một bước đầu tiên trong việc kiểm soát sự thay đổi là xác định các mục phần mềm phải được kiểm soát Điều này liên quan đến sự hiểu biết các cấu hình phần mềm trong bối cảnh của các cấu hình hệ thống, lựa chọn các cấu hình phần mềm, phát triển một chiến lược cho các nhãn ghi phần mềm và miêu tả mối quanheej của họ, và xác định các baseline sẽ được sử dụng, cùng với các thủ tục mua lại của một đường cơ sở của các mục

Cấu hình phần mềm (Software Configuration)

Một cấu hình phần mềm là việc thiết lập đặc tính chức năng và vật lý của phần mềm như quy định trong tài liệu hướng dẫn kỹ thuật hoặc đạt được trong

một sản phẩm Nó có thể được xem như là một phần của một cấu hình hệ thống tổng thể.

Mục cấu hình phần mềm (Software Configuration Item)

Một mục cấu hình phần mềm (SCI) là một tập hợp các phần mềm dành riêng cho quản lý cấu hình và được coi như mọt thực thể duy nhất trong quá trình SCM Một loạt các mục khác, khi thêm vào mã riêng của mình, thường kiểm soát bởi SCM Các mục phần mềm có tiềm năng để trở thành SCIS bao gồm các kế hoạch, chi tiết kỹ thuật và tài liệu thiết kế, các công cụ phần mềm,

mã nguồn và mã thực thi, bộ thư viện mã, dữ liệu và dữ liệu từ điển, và tài liệu hướng dẫn để cài đặt, bảo trì, điều hành, và sử dụng phần mềm

Việc lựa chọn SCIS là một quá trình quan trọng, trong đó phải có được một sự cân bằng giữa việc cung cấp khả năng hiển thị đầy đủ cho các mục đích kiểm soát dự án và cung cấp số lượng quản lý của các mục được kiểm soát

Các mối quan hệ mục cấu hình phần mềm (Software Configuration Item Relationships)

Các mối quan hệ cấu trúc giữa các SCI được chọn, và các bộ phận cấu thành của mình, ảnh hưởng đến các hoạt động SCM hoặc các nhiệm vụ khác, chẳng hạn như phần mềm xây dựng hoặc phân tích tác động của sự thay đổi đề xuất Việc theo dõi thích hợp của các mối quan hệ cũng rất quan trọng để hỗ trợ truy tìm nguồn gốc Thiết kế của đề án nhận dạng cho SCIs nên xem xét sự cần thiết phải ánh xạ để định danh các mục cấu trúc phần mềm, cũng như cần có để

hỗ trợ cho sự tiến triển của các mục phần mềm và các mối quan hệ của chúng

Phiên bản phần mềm (Software Version)

Các mục phần mềm mở rộng ra như là một tiền dự án phần mềm Một phiên bản của một mục phần mềm là một sản phẩm cụ thể được xác định và

được định rõ Nó có thể được dùng như một trạng thái của một mục phát triển Một bản duyệt lại là một phiên bản mới của một mục đó được thay thế phiên bản cũ của mục đó Một biến thể là một phiên bản mới của một mục cái sẽ được thêm vào cấu hình mà không thay thế cho phiên bản cũ.

Baseline

Một baseline phần mềm là một tập hợp các mục cấu hình phần mềm chính thức chỉ định và cố định tại một thời gian cụ thể trong vòng đời phần mềm Thuật ngữ này cũng được sử dụng để chỉ một phiên bản đặc biệt của một mục cấu hình phần mềm đã được thỏa thuận trên Trong cả hai trường hợp, các baseline chỉ có thể được thay đổi qua những thủ tục thay đổi kiểm soát chính thức Một baseline, cùng với tất cả thay đổi được chấp thuận cho baseline đại diện cho cấu hình được phê duyệt hiện hành

Thường thì được sử dụng baselines là những chức năng, cấp phát, phát triển, và baselines sản phẩm Các baseline chức năng tương ứng với các yêu cầu xét duyệt lại hệ thống Các baseline phân bổ tương ứng với các đặc điểm kỹ thuật xem xét các yêu cầu phần mềm và các yêu cầu đặc điểm kỹ thuật giao diện phần mềm Các baseline phát triển miêu tả các cấu hình phần mềm mở tại những thời điểm được lựa chọn trong vòng đời phần mềm Thay đổi quyền hạn cho các baseline này thường phụ thuộc chủ yếu với các tổ chức phát triển, nhưng có thể được chia sẻ với các tổ chức khác (ví dụ, SCM hay Test) Các sản phẩm baseline tương ứng với các sản phẩm phần mềm đã hoàn thành chuyển giao cho hệ thống hội nhập Các baselines sẽ được sử dụng cho một dự án nào

đó, cùng với các cấp của các cơ quan liên quan cần thiết để phê duyệt thay đổi,

là các kiểu được nhận dạng trong SCMP

Việc có được các mục cấu hình phần mềm (Acquiring Software Configuration Items)

Các mục cấu hình phần mềm được đặt dưới sự kiểm soát SCM vào các thời điểm khác nhau, có nghĩa là chúng được tích hợp vào một baseline cụ thể tại một điểm cụ thể trong vòng đời phần mềm Kích hoạt sự kiện này là hoàn thành một số hình thức chấp nhận nhiệm vụ chính thức, chẳng hạn như một bài đánh giá chính thức.

Đây là một việc nhận lại các hạng mục:

Hình 2: Thu nhận của các mụcNhận lại của một SCI, các thay đổi đối với mục đó phải được chính thức chấp nhận như là sự thích hợp cho các SCI và baseline có liên quan, như được định nghĩa trong SCMP Phê duyệt, mục được tích hợp vào các baseline phần mềm theo các thủ tục thích hợp

Thư viện phần mềm (Software Library)

Một thư viện phần mềm là một bộ sưu tập của phần mềm kiểm soát và tài liệu liên quan được thiết kế để hỗ trợ trong phát triển phần mềm, sử dụng và bảo trì Nó cũng là công cụ trong việc quản lý phát hành phần mềm và phân phối các hoạt động Một vài loại của các thư viện có thể được sử dụng, mỗi loại tương ứng với một mức độ cụ thể của sự trưởng thành của sản phẩm phần mềm Ví dụ, một thư viện làm việc có thể hỗ trợ mã háo và một thư viện có thể hỗ trợ dự án thử nghiệm, trong khi một thư viện tổng thể có thể được sử dụng cho các sản phẩm hoàn thành Một mức độ phù hợp của việc kiểm soát SCM (kết hợp baseline và cấp quyền cho các thay đổi) là liên kết với mỗi thư viện Vấn đề an ninh, trong các mục của kiểm soát truy cập và các cơ sở dự phòng, là một khía cạnh quan trọng của quản lý thư viện.

Các công cụ được sử dụng cho mỗi thư viện phải hỗ trợ kiểm soát SCM cần cho các thư viện đó, cả trong các mục về việc kiểm soát SCIS và kiểm soát truy cập vào thư viện Ở cấp thư viện làm việc, đây là một khả năng quản lý mã (code) phục vụ người phát triển, bảo trì và quản lý cấu hình phần mềm Nó tập trung vào việc quản lý phiên bản của các mục phần mềm trong khi hỗ trợ các hoạt động của các nhà đa phát triển Ở cấp độ cao hơn trong kiểm soát, truy cập

bị giới hạn hơn và SCM là người dùng chính

Các thư viện cũng là một nguồn thông tin quan trọng cho phép đo của công việc và các tiến trình

Kiểm soát cấu hình phần mềm (Software configuration control)

Kiểm soát cấu hình phần mềm là có liên quan đến việc quản lý các thay đổi trong vòng đời phần mềm Nó bao gồm các quy định để xác định những gì thay đổi để thực hiện, thẩm quyền cho phê duyệt các thay đổi nhất định, hỗ trợ cho việc thực thi những thay đổi đó, và khái niệm của các độ lệch chính thức từ các yêu cầu của dự án, cũng sự từ bỏ (waivers) của chúng

Yêu cầu, đánh giá và phê duyệt các thay đổi phần mềm

Bước đầu tiên trong việc quản lý các thay đổi cho các mục được điều khiển là xác định những gì thay đổi phải thực hiện Quy trình change request phần mềm cung cấp các thủ tục chính thức nộp để xem xét và các yêu cầu bản ghi thay đổi, đánh giá chi phí tiềm năng và tác động của sự thay đổi đề xuất, chấp nhận, sửa đổi, hay từ chối đề nghị sửa đổi Yêu cầu cho việc thay đổi cho các mục cấu hình phần mềm có thể có nguồn gốc bởi bất cứ ai tại thời điểm bất

kỳ nào trong vòng đời phần mềm và có thể bao gồm một giải pháp được đề xuất

và ưu tiên yêu cầu Một nguồn của các yêu cầu thay đổi là bắt đầu của hoạt động sửa sai để đáp ứng với báo cáo các vấn đề báo cáo Không kể đến nguồn, các loại thay đổi (ví dụ lỗi hoặc nâng cao) thường được ghi nhận trên SCR

Hình 3: Quy trình cung cấp các thủ tục chính thức để kiểm soát thay đổiQuy trình kiểm soát thay đổi này cung cấp một cơ hội cho việc theo dõi các nhược điểm và thu thập các phép đo hoạt động thay đổi theo loại thay đổi

Khi một SCR được chấp nhận, đánh giá kỹ thuật (còn gọi là phân tích tác động) được thực hiện để xác định mức độ của những sửa đổi đó sẽ là cần thiết cho các yêu cầu thay đổi được chấp nhận Việc hiểu biết rõ về các mối quan hệ giữa các mục phần mềm (và có thể cả phần cứng) là rất quan trọng cho công việc này Cuối cùng, một ban thẩm quyền thành lập, tương xứng với baseline bị ảnh hưởng, các SCI được tham gia, và bản chất của việc thay đổi, sẽ đánh giá khía cạnh kỹ thuật và quản lý của các yêu cầu thay đổi và hoặc là chấp nhận, sửa đổi, từ chối, hay hoãn việc đề xuất thay đổi.

Ban kiểm soát cấu hình phần mềm (Software CCB)

Thẩm quyền cho việc cho phép hay từ chối đề nghị thay đổi về một thực thể thường được biết đến như là một Hội đồng kiểm soát cấu hình (CCB) Trong các dự án nhỏ hơn, cơ quan này thực sự có thể tồn tại với leader hay một cá nhân được giao khứ không phải là một người đa ban Có thể có nhiều cấp độ thẩm quyền thay đổi tùy thuộc vào một loạt các tiêu chuẩn, như tới hạn của mục tham gia, bản chất của sự thay đổi (ví dụ tác động đến ngân sách và kế hoạch làm việc) hoặc các điểm hiện tại trong vòng đời Thành phần CCBs được sử dụng cho một thệ thống được thay đổi tùy theo các tiêu chí này (một đại diện của quản lý cấu hình phần phần mềm sẽ luôn có mặt) Tất cả các bên liên quan, phù hợp với trình độ của các ban kiểm soát cấu hình, được đại diện Khi phạm

vi quyền hạn của một ban kiểm soát cấu hình là một phần mềm tuyệt đối, nó được biết đến như một hội đồng quản lý cấu hình phần mềm (SCCB) Các hoạt động của CCB thường tùy thuộc vào chất lượng ghi nhận hoặc xem xét lại phần mềm

Xử lý yêu cầu thay đổi phần mềm (Software change request process)

Một phần thay đổi yêu cầu hiệu quả (Software Change Request - SCR)

xử lý yêu cầu việc sử dụng các công cụ hỗ trợ và các thủ tục khác nhau, từ dạng

giấy và một thủ tục một tài liệu cho một công cụ điện tử cho các yêu cầu thay đổi, thực thi các flow của một quá trình thay đổi, buộc ban quản lý cấu hình thay quyết định, và báo cáo quá trình thay đổi thông tin Một liên kết giữa công cụ có khả năng này và vấn đề báo cáo hệ thống có thể tạo điều kiện cho việc theo dõi các giải pháp cho các vấn đề được yêu cầu Thay đổi các mô tả quá trình và hỗ trợ các hình thức (thông tin) được cho vào một loạt các tài liệu tham khảo.

Thực thi các thay đổi phần mềm (Implementing software change)

Chấp thuận SCRs được thực hiện bằng cách sử dụng các thủ tục phần mềm được xác định phù hợp với các yêu cầu về tiến độ áp dụng Kể từ khi một

số SCRs chấp thuận có thể được thực hiện đồng thời, nó là cần thiết để cung cấp một phương tiện để theo dõi SCRs được tích hợp vào phiên bản phần mềm nói riêng và baseline Là một phần của quá trình thay đổi đóng, hoàn thành việc thay đổi có thể trải qua kiểm tra cấu hình và kiểm định chất lượng phần mềm Điều này bao gồm việc bảo đảm rằng chỉ các thay đổi được chấp thuận đã được thực hiện Các quy trình thay đổi yêu cầu được mô tả ở trên sẽ đặc trưng cho tài liệu SCM (và khác nữa) phê duyệt thông tin cho sự thay đổi

Việc hiện thực các thực thi của sự thay đổi được hỗ trợ bởi các khả năng của công cụ thư viện, trong đó cung cấp phiên bản và hỗ trợ quản lý cho code Tối thiểu, những công cụ này cung cấp khả năng kiểm soát phiên bản check-in/out và những cái liên quan Các công cụ mạnh mẽ có thể hỗ trợ phát triển song song và môi trường địa lý phân phối Những công cụ này có thể được biểu hiện như là các ứng dụng riêng biệt chuyên ngành thuộc thẩm quyền của một nhóm quản lý cấu hình phần mềm độc lập Họ cũng có thể xuất hiện như một phần của môi trường tích hợp công nghệ phần mềm Cuối cùng, đó có thể cơ bản như là một hệ thống kiểm soát thay đổi thô sơ được cung cấp với một hệ điều hành

Độ lệch và (waivers)

Các cưỡng ép được áp đặt trên một nỗ lực công nghệ phần mềm hoặc các chi tiết kỹ thuật sản xuất trong hoạt động phát triển có thể có quy định mà không thể thỏa mãn được ở thời điểm được thiết kế trong vòng đời của nó Độ lệch là một ủy quyền để khởi hành từ trước khi cung cấp một sự phát triển của mặt hàng đó Một waiver là một sự ủy quyền để sử dụng một mục, theo sau phát triển của nó, mà khởi hành từ việc cung cấp một cách nào đó Trong những trường hợp này, một quá trình chính thức được sử dụng để đạt được chấp thuận cho độ lệch từ, hoặc waivers, các quy định

Kiểm kê trạng thái cấu hình phần mềm (Software configuration status accounting)

Kiểm kê trạng thái cấu hình phần mềm (SCSA) là bản ghi và báo cáo của các thông tin cần thiết cho quản lý hiệu quả của cấu hình phần mềm

Thông tin trạng thái cấu hình phần mềm (Software configuration status information)

Các hoạt động SCSA thiết kế và vận hành một hệ thống để nắm bắt được

và báo cáo các thông tin cần thiết như tiến trình vòng đời Như trong bất kỳ hệ thống thông tin nào, các thông tin trạng thái cấu hình phải được quản lý cho các cấu hình tiến triển phải được xác định, thu thập và duy trì Các thông tin khác nhau và sự đo lường cần thiết để hỗ trợ quá trình quản lý cấu hình phần mềm và

để đáp ứng nhu cầu báo cáo tình trạng cấu hình quản lý, phần mềm kỹ thuật, và các hoạt động liên quan khác Các loại thông tin có sẵn bao gồm việc xác định cấu hình được chấp nhận, cũng như xác định và tình trạng thực hiện hiện tại của các thay đổi, độ lệch và waivers

Một số hình thức hỗ trợ công cụ tự động là cần thiết để thực hiện việc thu thập và nhiệm vụ báo cáo dữ liệu SCSA Điều này có thể là một khả năng cơ sở

dữ liệu, hoặc nó có thể là một công cụ độc lập hoặc một khả năng của một môi trường, lớn hơn công cụ tích hợp.

Báo cáo trạng thái cấu hình phần mềm (Software configuration status reporting)

Thông tin được báo cáo có để được sử dụng bởi các hoạt động tổ chức chất lượng khác nhau và các thành phần của dự án, bao gồm các nhóm phát triển, nhóm bảo trì, quản lý dự án, và phần mềm Báo cáo có thể dưới hình thức quảng cáo truy vấn để trả lời câu hỏi cụ thể hoặc định kỳ báo cáo được dự kiến trước Một số thông tin được tạo ra bởi các hoạt động kiểm kế tình trạng trong vòng đời có thể trở thành hồ sơ đảm bảo chất lượng

Ngoài việc báo cáo tình trạng hiện tại của cấu hình, thông tin thu được bằng các SCSA có thể phục vụ như là một cơ sở cho phép đo khác nhau của tầm quan trọng của quản lý, phát triển và quản lý cấu hình phàn mềm Ví dụ như số lượng yêu cầu thay đổi cho mỗi SCI và thời gian trung bình cần thiết để thực hiện một yêu cầu thay đổi

Ghi nhận cấu hình phần mềm (Software configuration auditing)

Ghi nhận một phần mềm là một hoạt động được thực hiện một cách độc lập đánh giá sự phù hợp của sản phẩm phần mềm và quy trình để áp dụng các luật, tiêu chuẩn, hướng dẫn, kế hoạch, và thủ tục Việc kiểm tra được hướng dẫn theo một quy trình cũng xác định gồm vai trò khác nhau và trách nhiệm kiểm toán viên Do vậy, mỗi người ghi nhận phải được giải thích cẩn thận Một người ghi nhận có thể yêu cầu một vài cá nhân thực hiện một loạt các nhiệm vụ trong một khoảng thời gian tương đối ngắn Công cụ để hỗ trợ việc lập kế hoạch và tiến hành ghi nhận rất có thể tạo thuận lợi cho quá trình

Hoạt động ghi nhận cấu hình phần mềm xác định mức độ mà một mục thỏa mãn yêu cầu chức năng và đặc điểm vật lý cần thiết Việc ghi nhận không chính thức của

loại này có thể được thực hiện tại các điểm quan trọng trong vòng đời Hai loại đánh giá hình thức có thể được yêu cầu bởi thỏa thuận quản trị (ví dụ, trong thỏa thuận bao gồm phần mềm quan trọng: Funtional Configuration Audit – FCA và Physical Configuration Audit – PCA Thành công khi hoàn thành việc ghi nhận này có thể là một điều kiện tiên quyết cho sự hình thành một sản phẩm baseline Mục đích tương phản Buckley của FCA và PCA trong phần cứng so với bối cảnh phần mềm, và đề nghị thẩm định cẩn thận về sự cần thiết cho một FCA phần mềm và một PCA trước khi thực hiện chúng.

Ghi nhận cấu hình chức năng phần mềm (Software functional configuration audit)

Mục đích của phần mềm FCA là để đảm bảo rằng các mục phần mềm được kiểm toán phù hợp với đặc điểm kỹ thuật của nó quản lý Sản lượng của phần mềm xác minh và xác nhận các hoạt động là một đầu vào chính cho việc kiểm toán này

Ghi nhận cấu hình vật lý phần mềm (Software physical configuration audit)

Mục đích của cấu hình phần mềm vật lý kiểm toán (PCA) là để đảm bảo rằng việc thiết kế và tài liệu tham khảo là phù hợp với xây dựng sản phẩm phần mềm

Trong quá trình ghi nhận của một phần mềm baseline

Như đã đề cập ở trên, kiểm toán có thể được thực hiện trong quá trình phát triển điều tra trạng thái hiện tại của các yếu tố cụ thể của cấu hình Trong trường hợp này, một kiểm toán có thể được áp dụng cho các mục baseline để chắc chắn rằng hiệu suất là phù hợp với đặc điểm kỹ thuật hoặc để đảm bảo phát triển các tài liệu tiếp tục là phù hợp với mục phát triển baseline

Phát hành phần mềm quản lý và giao hàng (Software release management divery)