1. Tổng quan Phạm
4.2 SCM quản lý
Thông tin SCM quản lý miêu tả vị trí của trách nhiệm và bản quyền của các hoạt động SCM với tổ chức và cá nhân bên trong cấu trúc dự án.
Thông tin SCM quản lý sẽ bao gồm 3 topic: dự án tổ chức cùng với cái mà SCM áp dụng, SCM trách nhiệm của các tổ chức, và các tham chiếu tới SCM chính sách và các chỉ thị áp dụng vào dự án.
4.2.1 Tổ chức
Ngữ cảnh tổ chức, cả công nghệ và ban quản lý trong phạm vi các hoạt động SCM đã lên kế hoạch được thực thi sẽ được miêu tả. Kế hoạch sẽ xác định như sau:
a) Tất cả cấc đơn vị tổ chức cái mà tham gia vào hay chịu trách nhiệm cho một vài hoạt động SCM trong dự án;
b) Các luật chức năng của những đơn vị tổ chức bên trong cấu trúc dự án; c) Mối quan hệ giữa các đơn vị tổ chức.
Các đơn vị tổ chức có thể bao gồm một người bán hàng (vendor) và khách hàng, một contractor chính, và các contractor con, có thể có cách hiệu quả cho thông tin hiện tại.
4.2.2 SCM trách nhiệm (SCM responsibilities)
Sự phân chia của các hoạt động SCM cho các đơn vị tổ chức sẽ được chỉ rõ. Với mỗi hoạt động được lên danh sách trong các hoạt động bên trong SCM (xem phần 4.3), tên của các đơn vị tổ chức hay tiêu đề công việc thực thi hành động này cũng sẽ được cung cấp. Một ma trận thuật lại các tổ chức được định nghĩa ở trên cho các chức năng của SCM, các hoạt động, và các nhiệm vụ có thể hữu ích cho tài liệu SCM trách nhiệm.
Với mỗi bảng tổng quan hay tổ chức riêng biệt được thành lập cho việc thực thi các hoạt động của SCM trong dự án này, kế hoạch sẽ miêu tả chúng:
a) Mục đích và mục tiêu;
b) Các thành phần và mối quan hệ giữa chúng; c) Thời điểm hiệu quả;
d) Phạm vi bản quyền (quyền hạn); e) Các thủ tục sẵn sàng.
4.2.3 Các chính sách, chỉ dẫn, và thủ tục có thể dùng (Appicable policies, directives, and procedures)
Một vài ràng buộc bên ngoài được đặt ở kế hoạch bởi những chính sách, chỉ dẫn và thủ tục khác sẽ được định nghĩa. Với mỗi chúng, nó ảnh hưởng và tác động lên kế hoạch sẽ được nói rõ.
4.3 Các hoạt động SCM (SCM activities)
Thông tin các hoạt động định nghĩa tất cả các chức năng và nhiệm vụ được yêu cầu để quản lý cấu hình của phần mềm hệ thống được định rõ trong phạm vi của Plan. Cả ban kỹ thuật và ban quản lý các hoạt động SCM đều được định danh. Các hoạt động dự án phổ biến có dính líu đến sẽ được miêu tả từ hình phối cảnh SCM.
Các hoạt động SCM đầu tiên được nhóm thành 4 chức năng: cấu hình nhận dạng, cấu hình điều khiển, tình trạng kế toán, và cấu hình ghi nhận và tổng quan. Thông tin yêu cầu cho mỗi chức năng được định nghĩa trong phần 4.3.1 đến 4.3.4.
Thông qua rủi ro tự nhiên cao, các yêu cầu cho giao diện điều khiển và contractor con/vendor các hoạt động điều khiển được định nghĩa một tách biệt nhau trong phần 4.3.5 và 4.3.6.
4.3.1Định danh cấu hình (Configuration identification)
Các hoạt động cấu hình nhận dạng sẽ định danh, đặt tên và miêu tả vật lý và đặc tính chức năng bằng tài liệu hướng dẫn của mã, chi tiết kỹ thuật, thiết kế, và yếu
tố dữ liệu được kiểm soát cho dự án. Các tài liệu được yêu cầu cho cấu hình điều khiển. Các mục được kiểm soát có thể ở giữa và cuối đầu ra (như mã thực thi, mã nguồn, tư liệu người dùng, danh sách lập trình, cơ sở dữ liệu, và các trường hợp test, kế hoạch test, các đặc tả kỹ thuật, và kế hoạch quản lý) và các yếu tố của môi trường hỗ trợ (như trình biên dịch, hệ thống vận hàn, công cụ lập trình và test).
Kế hoạch sẽ xác định các mục cấu hình của dự án (CI) và cấu trúc của chúng tại mỗi điểm điều khiển của dự án. Kế hoạch sẽ xác định làm thế nào mỗi CI và phiên bản của nó được đặt tên riêng biệt và miêu tả các hoạt động được thực thi để định nghĩa, theo dõi, lưu trữ và tìm lại CIs. Thông tin được yêu cầu cho cấu hình nhận dạng (xem hình 1) được đặc tả trong 4.3.1.1 đến 4.3.1.3.
Hình 1.1 – Các xử lý cấu hình nhận dạng.
Plan sẽ lưu trữ các mục được điều khiển, dự án CIs, và định nghĩa chúng như chúng suy ra hay được chọn. Plan sẽ còn được miêu tả làm thế nào liệt kê các mục và cấu trúc được sửa chữa cho dự án. Một cách tối thiểu, tất cả CIs được phân phát đều được lên danh sách.
Các baseline thích hợp sẽ được định nghĩa ở điểm điều khiển bên trong vòng đời của dự án trong các giới hạn sau:
a) Sự kiện tạo ra baseline;
b) Các mục được điều khiển bởi baseline;
c) Các thủ tục được dùng để tích hợp và thay đổi baseline;
d) Quyền hạn được yêu cầu để chấp thuận các thay đổi để các tài liệu baseline được phê chuẩn.
Ý nghĩa của các thay đổi định danh (nhận dạng) và liên kết chúng với CIs hiệu quả và thuật lại baseline đã được chỉ rõ.
4.3.1.2 Đặt tên các mục cấu hình (Naming configuration items)
Plan sẽ định rõ hệ thống nhận dạng cho việc phân chia các cá nhân duy nhất để mỗi mục đều được kiểm soát. Nó sẽ còn chỉ rõ làm thế nào các phiên bản khác nhau của chúng được nhận dạng rõ ràng. Các phương thức nhận dạng có thể bao gồm việc đặt tên theo quy ước và số phiên bản và các kí tự.
Bản kế hoạch sẽ miêu tả các phương thức cho việc đặt tên các mục kiểm soát cho mục đích lưu trữ, lấy lại, theo dõi, sao chép và phân phối. Các hoạt động bao gồm tạo phiên bản tạo nhãn của tài liệu và triển khai phần mềm, xuất bản thành kỳ và tạo mục được thay đổi cho mã triển khai hay dữ liệu được nhúng vào vi mạch, và nhận dạng gói vật lý.
Phần mềm được subcontractor, vendor proprietary software, và hỗ trợ phần mềm có thể yêu cầu chỉ rõ nhận dạng sự phối hợp và tạo nhãn.
4.3.1.3 Các mục cấu hình đạt được (Acquiring configuration items)
Plan sẽ nhận dạng các thư viện phần mềm được kiểm soát cho dự án và miêu tả làm thế nào để code, tài liệu, và dữ liệu của nhận dạng các baseline được định vị địa lý dưới thư viện điều khiển thích hợp. Với mỗi thư viện định dạng, định vị, yêu cầu tài liệu, các yêu cầu chấp nhận và sự kiểm tra, và thủ tục điều khiển truy cập được định rõ.
Plan sẽ mô tả thủ tục cho lưu trữ thực sự của các tài liệu và sức hút media, bao gồm cả việc tạo dấu vật lý và nhãn của các mục. Dữ liệu giữ được các thời điểm và sự ngăn ngừa tai họa và thủ tục khôi phục có thể được miêu tả.
Các thủ tục sẽ được miêu tả làm thế nào để lấy lại và các mục sao chép được kiểm soát từ thư viện lưu trữ. Những hoạt động này bao gồm sự xác minh của việc tạo dấu, nhãn, và theo dõi các bản copy được điều khiển và sự bảo vệ của bản quyền và bảo mật thông tin.
4.3.2Kiểm soát cấu hình (Configuration control)
Các hoạt đông kiểm soát cấu hình yêu cầu, đánh giá, phê chuẩn hay không phê chuẩn, và thực thi các thay đổi cho các baseline CIs. Các thay đổi chứa đựng cả việc sửa chữa và làm tăng lỗi. Mức độ của thủ tục cần thiết cho xử lý thay đổi phụ thuộc vào hiệu quả baseline dự án và vào sự va chạm thay đổi bên trong cấu trúc cấu hình.
Với mỗi dự án thư viện phần mềm được nhận dạng theo phần 4.3.1.3, kế hoạch sẽ miêu tả điều khiển thay đổi được áp đặt vào baseline CIs. Kế hoạch sẽ định nghĩa các luồng sau của bước cụ thể:
a) Nhận dạng và dữ liệu của sự cần thiết cho một thay đổi; b) Phân tích và đánh giá của một yêu cầu thay đổi;
c) Sự phê chuẩn hay không phê chuẩn của một yêu cầu; d) Việc kiểm tra, thực thi, và release của một thay đổi.
Kế hoạch sẽ nhận dạng các bản ghi (bản lưu trữ) để theo dõi và chứng minh bằng tài liệu yêu cầu này của các bước cho mỗi thay đổi. Một số khác trong việc nắm bắt những thay đổi dựa trên nguồn gốc của yêu cầu sẽ được chứng minh bằng tài liệu một cách rõ ràng.
4.3.2.1 Yêu cầu các thay đổi (Requesting changes)
Plan sẽ chỉ rõ các thủ tục yêu cầu một thay đổi tới một baseline CI và thông tin được chứng minh bằng tài liệu cho yêu cầu. Ít nhất, thông tin được lưu trữ cho thay đổi được đề xuất sẽ bao gồm:
a) Tên và phiên bản của CIs khi có vấn đề xuất hiện; b) Tên người sáng tạo và tổ chức;
c) Ngày yêu cầu;
d) Chỉ số khẩn cấp(Indication of urgency); e) Sự cần thiết của thay đổi;
f) Việc miêu tả của thay đổi được yêu cầu.
Việc thêm thông tin, như quyền ưu tiên hay sự phân loại, có thể được tính cả đến việc làm rõ ý nghĩa của yêu cầu và giúp đỡ trong việc phân tích và đánh giá. Thông tin khác, như số thay đổi yêu cầu, trạng thái, và sự sắp xếp, có thể được lưu trữ hay thay đổi theo dõi.
4.3.2.2 Đánh giá các thay đổi (Evaluating changes)
Plan sẽ chỉ rõ các phân tích yêu cầu để xác định sự va chạm của thay đổi được đề xuất và các thủ tục cho các kết quả tổng quan của việc phân tích. Các thay đổi sẽ
được đánh giá dựa theo hiệu quả của chúng trên sự phân phát và sự tác động giữa chúng trong các nguồn dự án.
4.3.2.3 Phê chuẩn hay không phê chuẩn các thay đổi (Approving or
disapproving changes)
Plan sẽ nhận dạng mỗi Hội đồng quản lý cấu hình (CCB) và mức của quyền hạn cho việc phê chuẩn được đưa ra các thay đổi. Một CCB có thể là độc lập hay là một nhóm. Tính đa cấp của CCBs có thể được xác định rõ, phụ thuộc vào mức độ phức tạp của hệ thống hay dự án và phụ thuộc vào dự án baseline được gọi lên. Khi đa CCBs được sử dụng, Plan sẽ chỉ ra làm thế nào mức thích đáng được xác định cho yêu cầu thay đổi, bao gồm một vài sự thay đổi trong vòng đời dự án.
Với một vài CCB được tận dụng, kế hoạch sẽ biểu thị cấp độ thẩm quyền và trách nhiệm của nó như đã định nghĩa trong phần 4.2.2.
4.3.2.4 Thực thi các thay đổi (Implementing changes)
Plan sẽ chỉ rõ các hoạt động cho việc thẩm tra (xác minh) và thực thi một thay đổi được phê chuẩn. Thông tin được lưu trữ cho việc hoàn thành một thay đổi sẽ bao gồm một số giới hạn sau:
a) Các yêu cầu thay đổi được kết hợp lại;
b) Tên và phiên bản cảu các mục được thực hiện; c) Xác minh ngày và chịu trách nhiệm tham gia;
d) Release hay việc cài đặt ngày và chịu trách nhiệm tham gia; e) Người nhận dạng của một phiên bản mới.
Thêm vào thông tin, như phần mềm lỗi hay việc nhận dạng của phần mềm hỗ trợ được sử dụng cho việc thực thi thay đổi, có thể được đưa vào.
Plan còn chỉ rõ các hoạt động cho kế hoạch release và kiểm soát, ví dụ như: cấu hình lại CIs, và việc phân phát một baseline mới.
4.3.3Cấu hình trạng thái kế toán (Configuration status accounting) Plan sẽ bao gồm thông tin sau:
a) Các yếu tố dữ liệu nào được theo dõi và báo cáo cho baseline và thay đổi; b) Các kiểu trạng thái kế toán báo cáo nào được phát sinh và thường xuyên
xảy ra;
c) Làm thế nào để thông tin được tập hợp lại, lưu trữ, xử lý và báo cáo; d) Làm thế nào để việc truy xuất vào trạng thái dữ liệu được kiểm soát. Nếu một hệ thống được tự động sử dụng cho một vài hoạt động kế toán, chức năng của nó sẽ được miêu tả hay xem xét đến.
Các yếu tố dữ liệu tối thiểu sau sẽ được theo dõi và báo cáo cho mỗi CI: phiên bản khởi tạo của nó được phê chuẩn, trạng thái của các thay đổi được yêu cầu, và trạng thái thực thi của các thay đổi được phê chuẩn. Mức độ chi tiết và dữ liệu xác định được yêu cầu có thể biến đổi việc ghi nhận các thông tin cần thiết của dự án và khách hàng.
4.3.4Ghi nhận cấu hình và xem xét lại (Configuration audits and reviews)
Ghi nhận cấu hình xác định phạm vi CI thực phản hồi lại yêu cầu vật lý và đặc tả chức năng. Cấu hình tổng quan là công cụ quản lý cho việc thiết lập baseline.
Kế hoạch sẽ nhận dạng việc ghi nhận cấu hình và tổng quan cho dự án. Nhỏ nhất, một ghi nhận cấu hình sẽ được thực thi ở CI ưu tiên để release.
Với mỗi ghi nhận cấu hình được lên kế hoạch, kế hoạch sẽ xác định: a) Mục tiêu của nó;
c) Kế hoạch làm việc của nhiệm vụ kiểm ghi nhận và xem xét lại; d) Thủ tục cho cách chỉ đạo ghi nhận hay xem xét lại;
e) Những người tham dự bởi tiêu đề công việc;
f) Tài liệu được yêu cầu có thể cho việc xem xét lại hay hỗ trợ cho việc ghi nhận hay xem xét lại;
g) Thủ tục cho việc lưu trữ một vài thiếu hụt và việc báo cáo chính xác; h) Sự phê chuẩn tiêu chuẩn và chỉ rõ hoạt động xuất hiện khi phê chuẩn. 4.3.5Kiểm soát giao diện (Interface control)
Các hoạt động kiểm soát giao diện coordinate changes cho dự án CIs với các thay đổi các mục giao diện bên ngoài phạm vi của Plan. Phần cứng, hệ thống phần mềm và hỗ trợ phần mềm, như những dự án khác và các trình bày khác, sẽ được khảo sát cho hiệu quả về giao diện cao trong dự án.
Plan sẽ nhận dạng các mục bên ngoài với các dự án giao diện phần mềm. Cho mỗi giao diện, dự án sẽ định nghĩa:
a) Bản chất của giao diện; b) Các tổ chức hiệu quả;
c) Làm thế nào mã giao diện, tài liệu, và dữ liệu được kiểm soát;
d) Làm thế nào các tài liệu giao diện điều khiển được phê chuẩn và release vào trong một baseline được định rõ.
Một vài CCB được thiết lập để kiểm soát giao diện, Plan sẽ nhận dạng trách nhiệm của nó và thủ tục được định rõ trong phần 4.2.2.
Các hoạt động kiểm soát subcontractor/vendor kết hợp chặt chẽ các mục được phát triển bên ngoài môi trường dự án vào trong dự án CIs. Bao gồm phần mềm được phát triển bởi kế ước và phần mềm được yêu cầu trong dạng thức đã hoàn thành. Chỉ rõ chú ý sẽ được chỉ đến hoạt động SCM thông qua việc thêm tổ chức và các mối quan hệ hợp pháp.
Với cả subcontracted và phần mềm được yêu cầu, Plan sẽ định nghĩa các hoạt động để kết hợp chặt chẽ các mục bên ngoài đã phát triển vào trong dự án CIs và coordinate changes cho các mục đó với việc phát triển các tổ chức.
Cho phần mềm được kí hợp đồng phụ (subcontracted), Plan sẽ miêu tả như sau:
a) Các yêu cầu SCM gì, bao gồm một SCM Plan là một phần của việc đồng ý một hợp đồng phụ.
b) Làm thế nào người kí hợp đồng phụ sẽ giám sát làm đúng theo yêu cầu; c) Ghi nhận cấu hình và phê duyệt của các mục hợp đồng phụ nào sẽ được
giữ;
d) Làm thế nào để code, tài liệu, dữ liệu bên ngoài được kiểm tra, sửa chữa, chấp nhận và hợp nhất với dự án phần mềm;
e) Làm thế nào các mục độc quyền được giữ cho việc bảo mật thông tin và có thể vạch ra của bản thân nó (Như là bản quyền và bản quyền tác giả); f) Làm thế nào các thay đổi được xử lý, bao gồm sự tham dự của hợp đồng
phụ.
Với phần mềm được yêu cầu, Plan sẽ miêu tả làm thế nào phần mềm được chấp nhận, kiểm tra và đặt ở SCM; làm thế nào các thay đổi cho người cung cấp phần mềm được xử lý, và làm thế nào người cung cấp bị lôi cuốn vào việc quản lý thay đổi
của dự án. Phần mềm được yêu cầu có thể trở thành một vendor, subcontractor, một khách hàng, một dự án khác, hay nguồn khác.