. III: Quản lý cấu hình software 3. Quản lý cấu hình software Hoạt động của quan lý cấu hình software Trước khi đi vào cụ thể, ta cần tìm hiểu hai khái niệm cơ bản trong quản lý cấu hình software: . hoạt động quản lý cấu hình software. • Đảm bảo các

Bạn đang xem: quản lý cấu hình phần mềm

Tài liệu quản lý cấu hình software

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (780.78 KB, 104 trang )

Đồ án tốt nghiệp Khoa công nghệ thông tin
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 tri thức nền tảng, chuyên môn thiết thực và quý hiếm. Này là những kiến
thức thiết yếu làm nền tảng phân tích cho việc phát triển trong nghề công nghệ
thông tin, cũng như trong công việc sau thời điểm ra trường. Trong số đó đồ án tốt
nghiệp là thời cơ để em có thể vận dụng, tổng kết lại những tri thức mà em đã
học. Đồng thời, rút ra được những kinh nghiệm thực tiễn và quý hiếm 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à đồng bọn cũng
như sự nỗ lực tìm tòi của chính bản thân mình, đã hỗ trợ em hoàn thiện đề tài một cách
thuận tiện. Tuy nhiên do thông tin update và kinh nghiệm thực tiễn còn tồn tại 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ẽ
thu được sự phản hồi 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 tình cảm ơn các thầy giáo viên trong khoa
Công Nghệ Thông Tin đã dạy dỗ em trong những năm qua.
Em xin chân tình cảm ơn thầy đã tận tình trợ giúp, chỉ bảo và tạo điều
kiện để em có thể hoàn thiện Đồ án tốt nghiệp này.
TPHCM, ngày …tháng…năm 2011
Sinh viên
Mục lục
1
Đồ án tốt nghiệp Khoa công nghệ thông tin
и
LỜI CẢM ƠN 1
Mục lục hình vẽ
Hình 1: Bản đồ của các dụng cụ và thủ tục để SCM hoạt động.
Hình 2: Thu nhận của các mục
Hình 3: Quy trình phân phối các thủ tục chính thức để kiểm tra thay đổi.

Hình 4: Test-in file
Hình 5: Test-out file
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
2
Đồ án tốt nghiệp Khoa công nghệ thông tin
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
3
Đồ án tốt nghiệp Khoa công nghệ thông tin
SCSA – Software Configuration Status Accouting
Chương Ι: Mở màn
1. Mở màn

Những ai quan tâm tới quy trình sản xuất software, 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 đơn giản 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 software thông dụng hiện tại 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 tiễn, 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 tất cả chúng ta khi làm các dự án về software đã tối thiểu một lần
gặp những tình huống như:
• Một lỗi nào đó của software đ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.
4
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Một tính năng (function) nào đó của software đã được phát triển và kiểm
tra thận trọng 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 xác minh hết sức thận trọng, đột 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 tính năng được chia ra cho nhiều lập trình viên, mỗi tính 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 tra chặt chẽ với mục đích để thiết lập và bảo
đảm tính vẹn toà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 software, xuyên suốt chu kỳ sống của dự án đó.
5
Đồ án tốt nghiệp Khoa công nghệ thông tin

Chương II: Quản lý chất lượng software
2. Quản lý chất lượng software
Quản lý chất lượng software
Quản lý chất lượng software là vấn đề không mới nhưng theo một số nhận xét
là còn yếu của các trung tâm tư vấn du học software Việt Nam. Một số trung tâm tư vấn du học trong nước hiện đã đoạ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 trung tâm tư vấn du học
gia công cho thị trường nước ngoài.
Lâu nay, nói đến chất lượng software, không ít người nghĩ ngay đến vấn đề là
xác nhận 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 xác minh software
(testing) như là hoạt động phụ trách chính. Với ý kiến của người tiêu dù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 software,
6
Đồ án tốt nghiệp Khoa công nghệ thông tin
đ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 tiễn thì việc xác minh hoạt
động software là trọng yếu nhưng không đủ đảm sản phẩm sẽ được hoàn thiện đúng
hạn và đúng yêu cầu. Xác minh 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 chuẩn đó 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 software, này là hệ
thống quản lý cấu hình software.
Một hệ thống quản lý cấu hình software thường có hai mục tiêu:
Thứ nhất: Xây dựng chất lượng cho software ngay từ thời kỳ khởi đầu. Điều
này đồng nghĩa với việc đảm bảo các yêu cầu cho software từ mọi nguồn khác nhau
phải được khái niệm, diễn dạt và hiểu một cách đúng đắn, giữa người mang ra yêu cầu
và người thực hiện yêu cầu.
Thứ hai: Đảm bảo chất lượng của software xuyên suốt quá trình phát triển.
Một hệ thống quản lý chất lượng software hoàn chỉnh bao gồm rất nhiều hoạt

động và phòng ban cấu thành, chúng khác nhau tùy vào 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 mưu hoạch (Planning)
3. Xem xét, xem lại (Reviewing)
4. Xác minh (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)
7
Đồ án tốt nghiệp Khoa công nghệ thông tin
8. Huấn luyện, huấn luyện (Education/Training)
9. Quản lý người phân phối, thầu phụ (Vendor Management)
10. Quản lý rủi ro (Risk Management)
Quản lý cấu hình software
Quy trình xây dựng software
Cũng như mọi nghề sản xuất khác, qui trình là một trong những yếu tố cực kỳ
trọng yếu mang lại sự thành công cho các nhà sản xuất software, 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 trung tâm tư vấn du học đều có thể
xử lý đồng bộ công việc tương ứng vị trí của mình thông qua phương thức chung của công
ty, hay tối thiểu ở cấp độ dự án. Có thể nói quy trình phát triển/xây dựng software
(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 ngân sách 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 software chính là phương pháp phát triển hay
sản xuất ra sản phẩm software. 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)
• Dụng cụ trợ giúp (Tools)
Với các nhóm việc chính:
8
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Đặc tả yêu cầu (Requirements Specification): Nêu ra những “đòi hỏi” cho cả
các yêu cầu tính năng và phi tính năng.
• Phát triển software (Development): Tạo ra software thỏa mãn các yêu
cầu được nêu ra trong “Đặc tả yêu cầu”.
• Kiểm thử software (Validation/Testing): Để đảm bảo software sản xuất
ra thỏa mãn những “đòi hỏi” được nêu ra trong “Đặc tả yêu cầu”.
• Thay đổi software (Evolution): Thỏa mãn nhu cầu thay đổi của người tiêu dùng.
Tùy thuộc mô hình phát triển software, 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 toàn bộ
các mô hình đều thích hợp cho mọi ứng dụng.
Khái niệm quản lý cấu hình software
Một hệ thống có thể được khái niệm là một tập hợp các thành phần tổ
chức để thực hiện một tính năng rõ ràng hoặc thiết lập các tính năng. Cấu hình
của một hệ thống là các tính năng và (hoặc) các đặc tính vật lý của phần cứng,
software hoặc các software được phối hợp theo quy trình rõ ràng xây dựng để
phục vụ một mục đích rõ ràng.
PM quản lý cấu hình (SCM) là một software trợ giúp quá trình xử
lý trong vòng đời software 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 tiêu dùng sản
phầm cuối cùng.
Những khái niệm về quản lý cấu hình vận dụng cho toàn bộ các mục phải
được kiểm tra, 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 software. Ta có thể tham khảo khái niệm 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

9
Đồ án tốt nghiệp Khoa công nghệ thông tin
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à thân thiện, quản lý cấu hình software 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ận
các cấu hình của một hệ thống tại các điểm nhấn trong thời gian cho mục
đích của hệ thống kiểm tra các thay đổi cấu hình, và duy trì sự vẹn toà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
khái niệm 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 software
Quản lý cấu hình tốt sẽ khắc phục đượ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:
• Update đồ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 𝓐 sử dụng kết quả công việc của
anh Ɓ, sản phẩm của anh Ɓ thay đổi có thể làm cho sản phẩm anh 𝓐
không chạy được nữa.
• Chia sẻ source code: Trong các hệ thống lớn, khi các tính năng
chung bị thay đổi, toàn bộ những người liên quan phải được biết.
10
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Phiên bản software (release): Hầu như 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 xác minh (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 toàn bộ các release sau đó.
Khi nào quản lý cấu hình software
Khi nào thì thiết yếu quản lý cấu hình software? 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 khởi đầu đến khi
kết thúc, thậm chí vẫn còn trong thời kỳ bảo trì sản phẩm sau dự án.
Chương III: Quản lý cấu hình software
3. Quản lý cấu hình software
Hoạt động của quan lý cấu hình software
Trước khi đi vào cụ thể, ta cần tìm hiểu hai khái niệm cơ bản trong quản lý cấu
hình software:
• 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 tra. 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, software…
11
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Baseline: Một điểm “mốc” được trao đổi 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 toàn bộ 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ừ ý kiến 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 rõ ràng 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 xác minh thúc đẩy

của sự thay đổi trước tiên ta hỏi:
– CI tác động những gì?
– Làm thế nào có các CI bị tác độ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 rõ ràng 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à khái niệm của một mục cấu hình có thể hành động như
là một từ ngữ thông dụng trên toàn bộ 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 rõ ràng có thể được xem như bước trước tiên trong việc phát
triển một thiết kế tổng thể từ trên xuống.
Plan quản lý cấu hình (CMP)
Thông thường, việc lập mưu hoạch cho quản lý cấu hình được trổ tài
trong tài liệu có tên Plan quản lý cấu hình (Configuration Manegement
Plan – CMP). Bản plan này thường bao gồm:
• Ý nghĩa, mục đích và phạm vi vận dụng của bản plan
12
Đồ án tốt nghiệp Khoa công nghệ thông tin
• 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. Khái niệm 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 người tiêu dùng,
người tiêu dùng đầu cuối.
• Dụng cụ (tool), môi trường (environment) và nền tảng hạ tầng
(infrastructure). Phần này mô tả các dụng cụ software hoặc quy
trình thủ tục được sử dụng trợ giúp quản lý cấu hình, ví dụ dụ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à giải trình cấu hình (configuration accounting and
reporting)
• Quy trình thủ tục lưu trữ và chép dự trữ (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ận 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ó kể cả việc mô tả tên, đánh số, đánh dấu
đặc trưng, giúp nhận thấy và phân biệt một CI với các CI hay thành phần khác.
13
Đồ án tốt nghiệp Khoa công nghệ thông tin
Bạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tiễn. Ví
dụ, người ta đánh số bàn trong quán ăn nhằm giúp người phục vụ mang đúng
thức ăn cho khách.Trong sản xuất software, 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 xem như là một CI, module
này có 2 file ExpMod.н và ExpMod.¢.
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 :
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 ra một khối tính năng được gom chung thành một CI.
Kiểm tra phiên bản (Version Control)
Có nhiều khái niệm và cách hiểu khác nhau về version control, ở đây chỉ
muốn khái niệm 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 tra các phiên bản (version) khác nhau của một

Xem Thêm  Top 12 kết quả tìm kiếm cách đổi màu layer trong photoshop mới nhất 2022

CI (kể cả 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 thời điểm đã qua một hoặc nhiều lần xem xét
và thay đổi. Hiện có nhiều dụng cụ trên thị trường trợ giúp cho việc kiểm tra
phiên bản, một số dụ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.
14
Đồ án tốt nghiệp Khoa công nghệ thông tin
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 trọng yếu của một CI có thể được đánh dấu để nhận thấy
một “mốc” trọng yếu 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 tiễn thường gặp các loại baseline sau:
• Tính năng (functional)
• Plan (planning)
• Yêu cầu (requirements).
• Sản phẩm (Product)
• Bản phân phối (Release)
• Xác minh (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 thời điểm các thay đổi đã
được chấp thuận và phê duyệt.
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” trọng yếu trong dự án. Đồng thời, trong quản lý
15
Đồ án tốt nghiệp Khoa công nghệ thông tin
baseline, vai trò và nhiệm vụ của những người thiết lập hoặc phê duyệt baseline
cũng phải được khái niệm.
Kiểm tra thay đổi (Change Control)
Khi phát triển hoặc bảo trì một sản phẩm software, 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 tra đầy đủ
toàn bộ các thay đổi tác động tới 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 người tiêu dùng, toàn bộ các chặng của quy trình phát
triển software từ thiết kế, đến viết code, đến xác minh 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 theo 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 tra thay đổi là mọi sự thay đổi phải
được thông báo đến toàn bộ 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 tra thay đổi bao gồm:
• Phân tích, phân tích
• Phê duyệt hoặc không phê duyệt
• Thực hiện việc thay đổi
• Xác minh việc thay đổi
• Xác lập baseline mới.
Trong kiểm tra 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)
16
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Trưởng nhóm (Technical Lead)

• Kỹ sư chất lượng (Quanlity Engineer)
• Và những ai bị tác động bởi các thay đổi.
Nhiệm vụ của Change Control Board thường là:
• Đảm bảo toàn bộ các thay đổi là được các phòng ban liên quan nhận thấy
và tham gia.
• Xem xét, phê duyệt hoặc phủ quyết các thay đổi trên các baseline.
• Xác minh, nhận các thay đổi.
• Phê duyệt 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 kể cả việc ghi nhận và giải trình 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, nhất là các CI
góp phần tạo ra sản phẩm. Nó trả lời những thắc mắc như: Có bao nhiêu file bị
tác động khi sửa chữa một lỗi software nào đó? Kết quả của công việc này
được ghi nhận trong một giải trình mang tên Configuration Status Accounting
Report (CSAR). Giải trình này thường làm rõ những điểm sau:
• Liệt kê toàn bộ baseline và CI thành phần hoặc có liên quan.
• Làm nổi trội 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 thiện, và các
baseline bị tác động (bởi sự thay đổi đó).
Việc giải trình này được làm thường xuyên và định kỳ, xuyên suốt dự án.
Audit
17
Đồ án tốt nghiệp Khoa công nghệ thông tin
Audit là một thuật ngữ rất thường dùng, cho nhiều nghề nghề khác
nhau, tuy nhiên trong ngành nghề 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
xác minh bao gồm:
• Đảm bảo các baseline tiên tiến nhất được liệt kê trong CSAR.

• Đảm bảo toàn bộ CI tạo ra một baseline được liệt kê.
• Xác minh 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 để nhất định rằng sự thay đổi trên CI là
hợp lý.
PCA (Physical Configuration Audit): Nhằm mục đích nhất đị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:
• Xác minh 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ận 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ó thỏa mãn yêu cầu khách hàng
hay không?
FCA (Functional Configuration Audit): Nhằm mục đích nhất định
những gì khách hàng yêu cầu được xác minh 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: Xác minh vết để phản ánh tính hai
chiều giữa yêu cầu khách hàng và việc xác minh sản phẩm.
Quản lý Release (Release Management)
18
Đồ án tốt nghiệp Khoa công nghệ thông tin
Trong thực tiễn, có nhiếu khái niệm khác nhau về khái niệm “release”. Về
cơ bản, tất cả chúng ta có thể hiểu: Quá trình phát triển một software 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 thỏa mãn một số yêu cầu đã định hoặc lập mưu
hoạch trước (theo yêu cầu khách hàng), sẽ được gởi cho khách hàng để xác minh
hoặc nhận xét. 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, thỉnh thoảng đượ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 giải trình CSAR (xem khái niệm ở 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ự trữ (Backup & Archive)
Lưu trữ và chép dự trữ 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 trọng yếu phải có của sản xuất software. 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/ software. Ở khía cạnh khác, nó trợ giúp 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ự trữ đòi hỏi toàn thể sản phẩm và sản phẩm trung
gian của dự án phải được định kỳ chép dự trữ trên những thiết bị hoặc những
19
Đồ án tốt nghiệp Khoa công nghệ thông tin
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 thể dữ liệu của dự án, tuân thủ quy trình lưu trữ đã được
thiết lập (khái niệm bởi dự án hoặc quy định ở cấp trung tâm tư vấn du học).
• 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 thời điểm đã
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) tính 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.
• Đảm bảo các baseline không bị thay đổi khi chưa được phê duyệt.

• 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 software.
• Đảm bảo các yêu cầu thiết yếu 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, dụng cụ trợ giúp
quản lý cấu hình…
20
Đồ án tốt nghiệp Khoa công nghệ thông tin
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ó tính năng như đã nói ở trên.
4. 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:
• Tuân thủ toàn bộ các quy định thủ tục của bản plan quản lý cấu
hình (CMP)
• Tham gia vào nhóm CCB khi có yêu cầu.
Quy trình quản lý cấu hình software
SCM điều khiển sự tiến hóa và vẹn toàn của một sản phẩm bằng xác nhận các
yếu tốt của nó, quản lý và kiểm tra sự thay đổi, xác minh, ghi lại và giải trình về thông
tin cấu hình. Đứng trên ý kiến của kỹ sư software, 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
plan và quản lý một cách thận trọng. Điều này, đòi hỏi một sự hiểu biết về cục diện
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.
Hoàn cảnh tổ chức
Để lập mưu hoạch xử lý quản lý cấu hình cho một dự án, thì vấn đề cần thiết
là phải hiểu cục diện 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 phụ trách về công nghệ software trợ giúp 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
21
Đồ án tốt nghiệp Khoa công nghệ thông tin
lý cấu hình thường thuộc về một yếu tố được tổ chức tách 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 đó, 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ể trợ giúp về theo dõi và báo
cáo về các cấu hình software rơi vào loại này.
Có vẻ mối quan hệ thân thiện nhất là sự phát triển software 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 tác động ràng buộc, việc chỉ đạo, việc xử lý quản lý cấu hình
tới từ một vài nguồn. Các quyết sách và thủ tục ở phía tập đoàn hay tổ chức các
cấp khác có thể tác độ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à
phân phối có thể quy định tác động đến quá trình quản lý cấu hình. Ví dụ, việc
xác minh cấu hình có thể được yêu cầu, hay nó có thể xác nhận rằng một số mặt
hàng được đặt theo quản lý cấu hình. Khi sản phẩm software được phát triển
có khả năng tác động đến an toàn công cộng, các đơn vị 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 software
tách biệt cho một dự án software và dụng cụ được chọn để thực thi thiết kế
software hiệu quả và việc thực thi của việc xử lý quản lý cấu hình software.
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ệ software do các tổ chức tiêu chuẩn khác nhau. Cung

22
Đồ án tốt nghiệp Khoa công nghệ thông tin
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 nâng cấp quy trình và các mô hình nhận xét quá trình
như các software của Engineering Institute’s Capability Maturity Model
Integration (SEI/CMMI) và ISO/IEC 15504 Sofware Engineering – Process
Asscessment (ISO/IEC 15504-98).
Plan SCM (Planing SCM)
Plan của một quá trình SCM cho một dự án nên được mang ra phù
phù hợp với cục diện của tổ chức, vận dụng những hạn chế, hướng dẫn thường được
chấp thuậ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 nghề được kiểm tra là: Nhận dạng cấu hình software, kiểm tra cấu
hình software, kiểm kê trạng thái cấu hình software, ghi nhận cấu hình phần
mềm, và software quản lý người phân phối, 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 dụng cụ và triển khai
thực hiện, nhà bán và kiểm tra 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 mưu hoạch được ghi lại trong một
plan quản lý cấu hình software (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 rõ ràng cho các hoạt động SCM hay các công việc
cũng 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 thể quyền và việc giải trình cho SCM cũng nên được xác nhận, mặc dù điều
này có thể được thực hiện tại thời kỳ quản lý dự án hoặc thời kỳ lập mưu
hoạch đảm bảo chất lượng.
23
Đồ án tốt nghiệp Khoa công nghệ thông tin
SCM nguồn lực và lịch trình (SCM resources and schedules)

Plan SCM xác nhận các nhân viên và các dụng cụ liên quan tới 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 thắc mắc
bằng cách thiết lập trình tự thiết yếu của SCM và xác nhận các mối quan hệ của
họ với lịch trình của dự án và cột mốc trọng yếu ở thời kỳ lập dự án quy
hoạch quản lý. Bất kể yêu cầu huấn luyện thiết yếu cho việc triển khai thực hiện kế
hoạch huấn luyện đội ngũ nhân viên và các thành viên mới cũng được xác nhận.
Chọn lựa dụng cụ và thực thi (Tool selection and implementation)
Khả năng khác nhau của các loại dụng cụ, và các thủ tục để họ sử dụng,
trợ giúp các hoạt động SCM. Tùy thuộc vào tình hình, khả năng các dụng cụ có
thể được làm sẵn với một số phối hợp các dụng cụ hướng dẫn sử dụng, các công
cụ tự động phân phối một khả năng SCM duy nhất, dụ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 dụng cụ phục vụ
cho nhu cầu của nhiều người tham gia trong quá trình công nghệ software.
Dụng cụ tự động trợ giúp ngày càng trở nên trọng yếu, 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 phân phối các dụng cụ trợ giúp cho:
• Thư viện SCM
• Yêu cầu thay đổi software (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ý
• Giải trình 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 software
• Quản lý và theo dõi tài liệu software
24
Đồ án tốt nghiệp Khoa công nghệ thông tin
• Thực hiện các software xây dựng
• Quản lý và theo dõi release và phân phối software của họ.
Các dụng cụ được sử dụng trong các phần này cũng có thể phân phối các
phép đo cho việc nâng cấp quy trình. Royce mô 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ệ software. Thông tin có sẵn từ các

Xem Thêm  Bỏ chế độ protected view trong excel 2010 - bỏ chế độ xem được bảo vệ trong word 2010

dụ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 ứng (Adaptability), MTBF (Mean Time Between Failures)
và trưởng thành (Maturity). Giải trình về những chỉ số này có thể được tổ chức lại
bằng nhiều cách khác nhau, ví dụ như bằng mục cấu hình software
(Software Configuration Item) hay bởi kiểu của thay đổi được yêu cầu (change
requested).
Tất cả 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 dụng cụ để SCM hoạt động:
25

Hình 4: Test-in fileHình 5: Test-out fileHình 6: Change request tracking system modelHình 7: Change request lỗiHình 8: New Change requestHình 9: Audit fileHình 10: Branch và child branchĐồ án tốt nghiệp Khoa công nghệ thông tinHình 1.1: Các xử lý cấu hình nhận dạng.Một số kí hiệu viết tắtCM – Configuration ManagementSCM – Software Configuration ManagementSEP – Software Engineering ProcessCI – Configuration ItemCMP – Configuration Management PlanCCB – Configuration Control BoardCSAR – Configuration Status Accounting ReportPCA – Physical Configuration AuditFCA – Functional Configuration AuditSCMP – Software Configuration Management PlanSQA – Software Quality AssuranceSCI – Software Configuration ItemSCR – Software Change RequestPM – Project ManagerĐồ án tốt nghiệp Khoa công nghệ thông tinSCSA – Software Configuration Status AccoutingChương Ι: Mở đầu1. Mở đầuNhững ai quan tâm tới quy trình sản xuất software, chắc hẳn không ít lần gặpkhái niệm về quản lý cấu hình (Configuration Management). Ta đơn giản tìm thấy cácyê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ẩnhoặc mô hình quy trình sản xuất software thông dụng hiện tại 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ầubắt buộc ngay từ mức 2, là mức cơ bản của mô hình này. Thực tiễn, có khá nhiều địnhnghĩ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ểmchung cơ bản.Chắc hẳn trong mỗi tất cả chúng ta khi làm các dự án về software đã tối thiểu một lầngặp những tình huống như:• Một lỗi nào đó của software đang xây dựng đã tốn nhiều công sức sửachữa, bỗng “thình lình” xuất hiện trở lại.Đồ án tốt nghiệp Khoa công nghệ thông tin• Một tính năng (function) nào đó của software đã được phát triển và kiểmtra thận trọng 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 xác minh hết sức thận trọng, bỗng nhiênkhô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ứcnăng, các tính năng được chia ra cho nhiều lập trình viên, mỗi chức năngbao 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 tinsource code với hàng trăm version, tập tin nào, version nào là đúng và cầnthiế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ấuhình được thực hiện nghiêm túc và kiểm tra chặt chẽ với mục đích để thiết lập và bảođảm tính vẹn toàn của các sản phẩm trung gian cũng như các sản phẩm sau cùng củamột dự án software, xuyên suốt chu kỳ sống của dự án đó.Đồ án tốt nghiệp Khoa công nghệ thông tinChương II: Quản lý chất lượng phần mềm2. Quản lý chất lượng phần mềmQuản lý chất lượng phần mềmQuản lý chất lượng software là vấn đề không mới nhưng theo một số đánh giálà còn yếu của các trung tâm tư vấn du học software Việt Nam. Một số trung tâm tư vấn du học trong nước hiện đã đạtcá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ầnmề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 tygia công cho thị trường nước ngoài.Lâu nay, nói đến chất lượng software, 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ầuhay không và cuối cùng thường quy về vai trò của hoạt động xác minh software(testing) như là hoạt động phụ trách chính. Với ý kiến của người tiêu dùng, điềunà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 software,Đồ án tốt nghiệp Khoa công nghệ thông tinđ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àmviệc có đúng như họ muốn hay không. Tuy nhiên trong thực tiễn thì việc xác minh hoạtđộng software là trọng yếu nhưng không đủ đảm sản phẩm sẽ được hoàn thiện đúnghạn và đúng yêu cầu. Xác minh 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ờigian để sửa chữa. Để đảm bảo được hai tiêu chuẩn đó của khách hang, đòi hỏi phải có mộtquy trình được thực thi xuyên suốt chu kỳ phát triển của dự án software, này là hệthống quản lý cấu hình software.Một hệ thống quản lý cấu hình software thường có hai mục tiêu:Thứ nhất: Xây dựng chất lượng cho software ngay từ thời kỳ khởi đầu. Điềunày đồng nghĩa với việc đảm bảo các yêu cầu cho software từ mọi nguồn khác nhauphải được khái niệm, diễn dạt và hiểu một cách đúng đắn, giữa người mang ra yêu cầuvà người thực hiện yêu cầu.Thứ hai: Đảm bảo chất lượng của software xuyên suốt quá trình phát triển.Một hệ thống quản lý chất lượng software hoàn chỉnh bao gồm rất nhiều hoạtđộng và phòng ban cấu thành, chúng khác nhau tùy vào 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 mưu hoạch (Planning)3. Xem xét, xem lại (Reviewing)4. Xác minh (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)Đồ án tốt nghiệp Khoa công nghệ thông tin8. Huấn luyện, huấn luyện (Education/Training)9. Quản lý người phân phối, thầu phụ (Vendor Management)10. Quản lý rủi ro (Risk Management)Quản lý cấu hình phần mềmQuy trình xây dựng phần mềmCũng như mọi nghề sản xuất khác, qui trình là một trong những yếu tố cực kỳquan trọng mang lại sự thành công cho các nhà sản xuất software, nó giúp cho mọithành viên trong dự án từ người cũ đến người mới, trong hay ngoài trung tâm tư vấn du học đều có thểxử lý đồng bộ công việc tương ứng vị trí của mình thông qua phương thức chung của côngty, hay tối thiểu ở cấp độ dự án. Có thể nói quy trình phát triển/xây dựng software(Software Development/Engineering Process – SEP) có tính chất quyết định để tạo rasản phẩm chất lượng tốt với ngân sách 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 software chính là phương pháp phát triển haysản xuất ra sản phẩm software. 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)• Dụng cụ trợ giúp (Tools)Với các nhóm việc chính:Đồ án tốt nghiệp Khoa công nghệ thông tin• Đặc tả yêu cầu (Requirements Specification): Nêu ra những “đòi hỏi” cho cảcác yêu cầu tính năng và phi tính năng.• Phát triển software (Development): Tạo ra software thỏa mãn các yêucầu được nêu ra trong “Đặc tả yêu cầu”.• Kiểm thử software (Validation/Testing): Để đảm bảo software sản xuấtra thỏa mãn những “đòi hỏi” được nêu ra trong “Đặc tả yêu cầu”.• Thay đổi software (Evolution): Thỏa mãn nhu cầu thay đổi của người tiêu dùng.Tùy thuộc mô hình phát triển software, các nhóm công việc được triển khaitheo những cách khác nhau. Để sản xuất cùng một sản phẩm phầm mềmngườ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.Khái niệm quản lý cấu hình phần mềmMột hệ thống có thể được khái niệm là một tập hợp các thành phần tổchức để thực hiện một tính năng rõ ràng hoặc thiết lập các tính năng. Cấu hìnhcủa một hệ thống là các tính năng và (hoặc) các đặc tính vật lý của phần cứng,software hoặc các software được phối hợp theo quy trình rõ ràng xây dựng đểphục vụ một mục đích rõ ràng.PM quản lý cấu hình (SCM) là một software trợ giúp quá trình xửlý trong vòng đời software 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 tiêu dùng sảnphầm cuối cùng.Những khái niệm về quản lý cấu hình vận dụng cho toàn bộ các mục phảiđược kiểm tra, mặc dù có một số khác biệt trong việc thực hiện giữa CM phầncứng và CM software. Ta có thể tham khảo khái niệm ngắn gọn sau từ CNNvà 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Đồ án tốt nghiệp Khoa công nghệ thông tintoà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à thân thiện, quản lý cấu hình software bao gồm cáccô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 địnhcác cấu hình của một hệ thống tại các điểm nhấn trong thời gian cho mụcđích của hệ thống kiểm tra các thay đổi cấu hình, và duy trì sự vẹn toà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átvề: đị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ềmQuản lý cấu hình tốt sẽ khắc phục được hàng loạt những khó khăn trongcác dự án, đặc biệt trong các dự án lớn:• Update đồng thời: Khi hai hoặc nhiều lập trình viên làm việc cáchbiệ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ủangười khác. Ví dụ: Sản phẩm anh 𝓐 sử dụng kết quả công việc củaanh Ɓ, sản phẩm của anh Ɓ thay đổi có thể làm cho sản phẩm anh Akhông chạy được nữa.• Chia sẻ source code: Trong các hệ thống lớn, khi các chức năngchung bị thay đổi, toàn bộ những người liên quan phải được biết.10Đồ án tốt nghiệp Khoa công nghệ thông tin• Phiên bản software (release): Hầu như 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 xác minh (test), và một release khác nữa đang trongquá 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 toàn bộ các release sau đó.Khi nào quản lý cấu hình phần mềmKhi nào thì thiết yếu quản lý cấu hình software? Quản lý cấu hình phầnmềm được thực hiện xuyên suốt chu kỳ sống của dự án, từ lúc khởi đầu đến khikết thúc, thậm chí vẫn còn trong thời kỳ bảo trì sản phẩm sau dự án.Chương III: Quản lý cấu hình phần mềm3. Quản lý cấu hình phần mềmHoạt động của quan lý cấu hình phần mềmTrước khi đi vào cụ thể, ta cần tìm hiểu hai khái niệm cơ bản trong quản lý cấuhình software:• Configuration Item – CI: định danh này trong quản lý cấu hình là têngọi của sản phẩm, sản phẩm trung gian, một tệp tin (file) hoặc nhómfile, 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ầusản phẩm, bản thiết kế, các mô hình, software…11Đồ án tốt nghiệp Khoa công nghệ thông tin• Baseline: Một điểm “mốc” được trao đổi bởi những người liênquan 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 toàn bộ những người liên quan. Một cách tổng quanquản lý cấu hình các nhóm hoạt động như hình vẽ….Từ ý kiến 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 rõ ràng của một mục cấu hình tạo ra một phiênbản mới của sản phẩm cùng một CI, bản thân một baseline. Trong xác minh tác độngcủa sự thay đổi trước tiên ta hỏi:- CI tác động những gì?- Làm thế nào có các CI bị tác độ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ợpcá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ácghi chú có thể chứa các đề mục rõ ràng 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ủamột sự thay đổi, danh sách và khái niệm của một mục cấu hình có thể hành động nhưlà một từ ngữ thông dụng trên toàn bộ 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 rõ ràng có thể được xem như bước trước tiên trong việc pháttriển một thiết kế tổng thể từ trên xuống.Plan quản lý cấu hình (CMP)Thông thường, việc lập mưu hoạch cho quản lý cấu hình được thể hiệntrong tài liệu có tên Plan quản lý cấu hình (Configuration ManegementPlan – CMP). Bản plan này thường bao gồm:• Ý nghĩa, mục đích và phạm vi vận dụng của bản kế hoạch12Đồ án tốt nghiệp Khoa công nghệ thông tin• Vai trò và trách nhiệm của nhóm, cá nhân trong dự án thực hiện cáchoạt động khác nhau liên quan đến quản lý cấu hình. Khái niệm 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 người tiêu dùng,người tiêu dùng đầu cuối.• Dụng cụ (tool), môi trường (environment) và nền tảng hạ tầng(infrastructure). Phần này mô tả các dụng cụ software hoặc quytrình thủ tục được sử dụng trợ giúp quản lý cấu hình, ví dụ công cụquản lý phiên bản sản phẩm (version control); mô tả vị trí các máychủ, 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 (ConfigurationControl Board – CCB)• Thông tin nơi lưu trữ các CI• Kiểm kê và giải trình cấu hình (configuration accounting andreporting)• Quy trình thủ tục lưu trữ và chép dự trữ (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ận tính duy nhất của một CI, cũng như mốiquan hệ của nó với các CI khác. Nó kể cả việc mô tả tên, đánh số, đánh dấuđặc trưng, giúp nhận thấy và phân biệt một CI với các CI hay thành phần khác.13Đồ án tốt nghiệp Khoa công nghệ thông tinBạn có thể nhận thấy hình thức định danh tương tự trong đời sống thực tiễn. Vídụ, người ta đánh số bàn trong quán ăn nhằm giúp người phục vụ mang đúngthức ăn cho khách.Trong sản xuất software, một CI có thể bao gồm một haynhiều file. Ví dụ: một module tên ExpMod có thể được xem như là một CI, modulenày có 2 file ExpMod.н và ExpMod.¢.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 :Số ID của dự án PRJ001Số ID của Item: REQBPhiên bản : 1.0.4_draft_BTrong 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 ra một khối tính năng được gom chung thành một CI.Kiểm tra phiên bản (Version Control)Có nhiều khái niệm và cách hiểu khác nhau về version control, ở đây chỉmuốn khái niệm 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 tra các phiên bản (version) khác nhau của mộtCI (kể cả việc định danh và sự lưu trữ CI đó).Thế phiên bản là gì? Một phiênbản là một thực thể mới của một CI sau thời điểm đã qua một hoặc nhiều lần xem xétvà thay đổi. Hiện có nhiều dụng cụ trên thị trường trợ giúp cho việc kiểm soátphiên bản, một số dụ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ênbản mới.14Đồ án tốt nghiệp Khoa công nghệ thông tinLư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ànhphần của CI đó. Trong ví dụ trên, phiên bản của CI “ExpMod” khác với phiênbản của file thành phần “ExpMod.h” và “ExpMod.c”. (Xem hình 3)Các phiên bản trọng yếu của một CI có thể được đánh dấu để nhận biếtmột “mốc” trọng yếu trong tiến trình phát triển CI đó, phiên bản mà CI đượcphê 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. Trongthực tế thường gặp các loại baseline sau:• Tính năng (functional)• Plan (planning)• Yêu cầu (requirements).• Sản phẩm (Product)• Bản phân phối (Release)• Xác minh (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 thời điểm các thay đổi đãđược chấp thuận và phê duyệt.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” trọng yếu trong dự án. Đồng thời, trong quản lý15Đồ án tốt nghiệp Khoa công nghệ thông tinbaseline, vai trò và nhiệm vụ của những người thiết lập hoặc phê duyệt baselinecũng phải được khái niệm.Kiểm tra thay đổi (Change Control)Khi phát triển hoặc bảo trì một sản phẩm software, việc thay đổi yêucầu là không thể tránh khỏi. Mục đích của change control là để kiểm tra đầy đủtất cả các thay đổi tác động tới việc phát triển một sản phẩm. Đôi lúc chỉ mộtvài yêu cầu thay đổi nhỏ của người tiêu dùng, toàn bộ các chặng của quy trình pháttriển software từ thiết kế, đến viết code, đến xác minh 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 theo rấtnhiề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 tra thay đổi là mọi sự thay đổi phảiđược thông báo đến toàn bộ 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 tra thay đổi bao gồm:• Phân tích, phân tích• Phê duyệt hoặc không phê duyệt• Thực hiện việc thay đổi• Xác minh việc thay đổi• Xác lập baseline mới.Trong kiểm tra thay đổi, ta cũng thường gặp khái niệm “hội đồng kiểmsoá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)16Đồ án tốt nghiệp Khoa công nghệ thông tin• Trưởng nhóm (Technical Lead)• Kỹ sư chất lượng (Quanlity Engineer)• Và những ai bị tác động bởi các thay đổi.Nhiệm vụ của Change Control Board thường là:• Đảm bảo toàn bộ các thay đổi là được các phòng ban liên quan nhận biếtvà tham gia.• Xem xét, phê duyệt hoặc phủ quyết các thay đổi trên các baseline.• Xác minh, nhận các thay đổi.• Phê duyệt 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 kể cả việc ghi nhận và giải trình tình trạng của các CIcũng như yêu cầu thay đổi, tập hợp số liệu thống kê về CI, nhất là các CIgóp phần tạo ra sản phẩm. Nó trả lời những thắc mắc như: Có bao nhiêu file bịảnh hưởng khi sửa chữa một lỗi software nào đó? Kết quả của công việc nàyđược ghi nhận trong một giải trình mang tên Configuration Status AccountingReport (CSAR). Giải trình này thường làm rõ những điểm sau:• Liệt kê toàn bộ baseline và CI thành phần hoặc có liên quan.• Làm nổi trội 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 thiện, và cácbaseline bị tác động (bởi sự thay đổi đó).Việc giải trình này được làm thường xuyên và định kỳ, xuyên suốt dự án.Audit17Đồ án tốt nghiệp Khoa công nghệ thông tinAudit là một thuật ngữ rất thường dùng, cho nhiều nghề nghề khácnhau, tuy nhiên trong ngành nghề 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ĩagầ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ệckiểm tra bao gồm:• Đảm bảo các baseline tiên tiến nhất được liệt kê trong CSAR.• Đảm bảo toàn bộ CI tạo ra một baseline được liệt kê.• Xác minh các CI đã bị thay đổi từ lần baseline trước đó, so sánh chúngvới các yêu cầu thay đổi để nhất định rằng sự thay đổi trên CI làhợp lý.PCA (Physical Configuration Audit): Nhằm mục đích nhất định xemnhững gì khách hàng yêu cầu có được thực hiện hay không. Gồm hai việc:• Xác minh vết để phản ánh tính hai chiều (tracebitily) giữa yêu cầukhách hàng và việc thực hiện code trong dự án.• Xác nhận những gì sẽ được phân phối cho khách hàng (Executablefile, source code, tài liệu đi kèm…) có thỏa mãn yêu cầu khách hànghay không?FCA (Functional Configuration Audit): Nhằm mục đích khẳng địnhnhững gì khách hàng yêu cầu được xác minh chặt chẽ trên sản phẩm tạo ra trướckhi giao cho khách hàng hay không. Gồm: Xác minh vết để phản ánh tính haichiều giữa yêu cầu khách hàng và việc xác minh sản phẩm.Quản lý Release (Release Management)18Đồán tốt nghiệp Khoa công nghệ thông tinTrong thực tiễn, có nhiếu khái niệm khác nhau về khái niệm “release”. Vềcơ bản, tất cả chúng ta có thể hiểu: Quá trình phát triển một software thường quanhiề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ấtnhiều bản “build” đó, một số bản thỏa mãn 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 trahoặc nhận xét. Các bản build này được gọi là “release”; công việc tạo ra và phânphối các bản release được gọi là công việc “release”. Theo cách hiểu này, sảnphẩm sau cùng cũng là một bản release, thỉnh thoảng được gọi là “finalrelease”.Trong quá trình release, việc quản lý đòi hỏi phải thực hiện các côngviệ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 giải trình CSAR (xem khái niệm ở 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àngLưu trữ và chép dự trữ (Backup & Archive)Lưu trữ và chép dự trữ 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 trọng yếu phải có của sản xuất software. Nó giúpkhắ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ặcsự cố phần cứng/ software. Ở khía cạnh khác, nó trợ giúp cho hoạt động versioncontrol (đã nói ở trên) trong trường hợp ta muốn sử dụng những version khácnhau. Lưu trữ và chép dự trữ đòi hỏi toàn thể sản phẩm và sản phẩm trunggian của dự án phải được định kỳ chép dự trữ trên những thiết bị hoặc những19Đồ án tốt nghiệp Khoa công nghệ thông tinnơ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ảithực hiện:• Lưu trữ toàn thể dữ liệu của dự án, tuân thủ quy trình lưu trữ đã đượcthiết lập (khái niệm bởi dự án hoặc quy định ở cấp trung tâm tư vấn du học).• 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 thời điểm đãchép lưu trữ.Vai trò của các thành viên trong dự ánTrong một dự án điển hình, thông thường có 4 (nhóm) tính 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ầnmềm của dự án.• Thiết lập các baseline, ghi nhận các thay đổi trên các baseline.• Đảm bảo các baseline không bị thay đổi khi chưa được phê duyệt.• 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 software.• Đảm bảo các yêu cầu thiết yếu 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, dụng cụ hỗ trợquản lý cấu hình…20Đồ án tốt nghiệp Khoa công nghệ thông tin3. 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ó tính năng như đã nói ở trên.4. Các thành viên của dự ánCác thành viên của dự án, kể cả CM, PM và thành viên CCB, có tráchnhiệm:• Tuân thủ toàn bộ các quy định thủ tục của bản plan quản lý cấuhình (CMP)• 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ềmSCM điều khiển sự tiến hóa và vẹn toàn của một sản phẩm bằng xác nhận cácyếu tốt của nó, quản lý và kiểm tra sự thay đổi, xác minh, ghi lại và giải trình về thôngtin cấu hình. Đứng trên ý kiến của kỹ sư software, SCM tạo điều kiện phát triểnvà 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ậpkế hoạch và quản lý một cách thận trọng. Điều này, đòi hỏi một sự hiểu biết về bối cảnhtổ 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.Hoàn cảnh tổ chứcĐể lập mưu hoạch xử lý quản lý cấu hình cho một dự án, thì vấn đề cần thiếtlà phải hiểu cục diện 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 phụ trách về công nghệ software trợ giúp 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ản21Đồ án tốt nghiệp Khoa công nghệ thông tinlý cấu hình thường thuộc về một yếu tố được tổ chức tách 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 đó, 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ủatổ chức. Quản lý non – configuration thường là trách nhiệm của hoạt động đảmbảo chất lượng, tuy nhiên, quản lý cấu hình có thể trợ giúp về theo dõi và báocáo về các cấu hình software rơi vào loại này.Có vẻ mối quan hệ thân thiện nhất là sự phát triển software và các tổ chứcbảo trì.Hạn chế và hướng dẫn cho tiến trình SCMNhững tác độ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 quyết sách và thủ tục ở phía tập đoàn hay tổ chức cáccấp khác có thể tác độ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 tác động đến quá trình quản lý cấu hình. Ví dụ, việckiểm tra cấu hình có thể được yêu cầu, hay nó có thể xác nhận rằng một số mặthàng được đặt theo quản lý cấu hình. Khi sản phẩm software được phát triểncó khả năng tác động đến an toàn công cộng, các đơn vị bên ngoài quy địnhcó 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ềmriêng biệt cho một dự án software và dụ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 software.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áctiêu chuẩn về công nghệ software do các tổ chức tiêu chuẩn khác nhau. Cung22Đồ án tốt nghiệp Khoa công nghệ thông tincấ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 nâng cấp quy trình và các mô hình nhận xét quá trìnhnhư các software của Engineering Institute’s Capability Maturity ModelIntegration (SEI/CMMI) và ISO/IEC 15504 Sofware Engineering – ProcessAsscessment (ISO/IEC 15504-98).Plan SCM (Planing SCM)Plan của một quá trình SCM cho một dự án nên được mang ra phùhợp với cục diện của tổ chức, vận dụng những hạn chế, hướng dẫn thường đượcchấ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 độngchuyên nghề được kiểm tra là: Nhận dạng cấu hình software, kiểm tra cấuhình software, kiểm kê trạng thái cấu hình software, ghi nhận cấu hình phầnmềm, và software quản lý người phân phối, 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 dụng cụ và triển khaithực hiện, nhà bán và kiểm tra 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 mưu hoạch được ghi lại trong mộtkế hoạch quản lý cấu hình software (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 SCMhay 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 rõ ràng cho các hoạt động SCM hay các công việccũ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 thể quyền và việc giải trình cho SCM cũng nên được xác nhận, mặc dù điềunày có thể được thực hiện tại thời kỳ quản lý dự án hoặc thời kỳ lập kếhoạch đảm bảo chất lượng.23Đồ án tốt nghiệp Khoa công nghệ thông tinSCM nguồn lực và lịch trình (SCM resources and schedules)Plan SCM xác nhận các nhân viên và các dụng cụ liên quan đến việcthự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ỏibằng cách thiết lập trình tự thiết yếu của SCM và xác nhận các mối quan hệ củahọ với lịch trình của dự án và cột mốc trọng yếu ở thời kỳ lập dự án quyhoạch quản lý. Bất kể yêu cầu huấn luyện thiết yếu cho việc triển khai thực hiện kếhoạch huấn luyện đội ngũ nhân viên và các thành viên mới cũng được xác nhận.Chọn lựa dụng cụ và thực thi (Tool selection and implementation)Khả năng khác nhau của các loại dụng cụ, và các thủ tục để họ sử dụng,trợ giúp các hoạt động SCM. Tùy thuộc vào tình hình, khả năng các dụng cụ cóthể được làm sẵn với một số phối hợp các dụng cụ hướng dẫn sử dụng, các côngcụ tự động phân phối một khả năng SCM duy nhất, dụng cụ tự động tích hợp mộtloạt các khả năng SCM, hoặc các môi trường được tích hợp dụng cụ phục vụcho nhu cầu của nhiều người tham gia trong quá trình công nghệ software.Dụng cụ tự động trợ giúp ngày càng trở nên trọng yếu, và ngày càng khó thiếtlậ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ênphức tạp hơn. Những khả năng phân phối các dụng cụ trợ giúp cho:• Thư viện SCM• Yêu cầu thay đổi software (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ý• Giải trình 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 software• Quản lý và theo dõi tài liệu phần mềm24Đồ án tốt nghiệp Khoa công nghệ thông tin• Thực hiện các software xây dựng• Quản lý và theo dõi release và phân phối software của họ.Các dụng cụ được sử dụng trong các phần này cũng có thể phân phối cácphép đo cho việc nâng cấp quy trình. Royce mô 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ệ software. Thông tin có sẵn từ cáccô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 ứng (Adaptability), MTBF (Mean Time Between Failures)và trưởng thành (Maturity). Giải trình về những chỉ số này có thể được tổ chức lạibằng nhiều cách khác nhau, ví dụ như bằng mục cấu hình software(Software ConfigurationItem) hay bởi kiểu của thay đổi được yêu cầu (changerequested).Tất cả chúng ta có thể hình dung một khả năng lập bản đồ và các thủ tục củacác dụng cụ để SCM hoạt động:25

Xem Thêm  Tải xuống DLL FIXER Số sê-ri khóa cấp phép - key dll-files fixer 2016


Xem thêm những thông tin liên quan đến đề tài quản lý cấu hình software

Chương 6: Quản lý Cấu hình PM

  • Tác giả: Phung Bui
  • Ngày đăng: 2021-03-31
  • Nhận xét: 4 ⭐ ( 4272 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Bài giảng: Quản lý cấu hình software
    Môn học: Nhập môn Công nghệ PM

Quản lý cấu hình software

  • Tác giả: 123docz.net
  • Nhận xét: 4 ⭐ ( 2114 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Quản lý cấu hình software – 123doc – thư viện trực tuyến, download tài liệu, tải tài liệu, sách, sách số, tài liệu, audio book, sách nói hàng đầu Việt Nam

Vì sao lại gọi là Quản lý cấu hình software (SCM)?

  • Tác giả: qastack.vn
  • Nhận xét: 3 ⭐ ( 5219 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: [Tìm thấy giải pháp!] Thuật ngữ quản lý cấu hình thuộc về từ vựng kỹ thuật chung. Mục đích của…

IT Configuration Management

  • Tác giả: infochief.com.vn
  • Nhận xét: 4 ⭐ ( 7690 lượt nhận xét )
  • Khớp với kết quả tìm kiếm:

Tiểu luận quản lý cấu hình software

  • Tác giả: tailieu.vn
  • Nhận xét: 3 ⭐ ( 4512 lượt nhận xét )
  • Khớp với kết quả tìm kiếm:

Các dụng cụ và software quản lý cấu hình mạng tốt nhất

  • Tác giả: nq.com.vn
  • Nhận xét: 5 ⭐ ( 4409 lượt nhận xét )
  • Khớp với kết quả tìm kiếm:

Chương 6: Quản lý Cấu hình PM

  • Tác giả: lienket.vn
  • Nhận xét: 4 ⭐ ( 1805 lượt nhận xét )
  • Khớp với kết quả tìm kiếm: Chương 6: Quản lý Cấu hình PM 27 , nan / #Chương #Quản #lý #Cấu #hình #Phần #mềm / Khái niệm software Bài giảng: Quản lý cấu hình software Môn học: Nhập môn Công nghệ PM Nguồn: https://lienket.vn/blog/ Xem thêm các Video Game khác tại: https://lienket.vn/blog/lap-trinh

Xem thêm các nội dung khác thuộc thể loại: Thủ thuật máy tính

By ads_php