BÁO CÁO MÔN NGUYÊN LÝ CÔNG NGHỆ PHẦN MỀM QUẢN LÝ CẤU HÌNH PHẦN MỀM

Tại sao cần quản lý cấu hình? Trong quá trình phát triển phần mềm, thay đổi là điều không thể tránh khỏi data other documents Test Project Plan changes in technical requirements change

QUẢN LÝ CẤU HÌNH PHẦN MỀM

( SOFTWARE CONFIGURATION MANAGEMENT )

Giảng Viên: PGS.TS Trần Đan Thư

Nhóm 10: Võ Duy Phúc

Nguyễn Tấn Cầm

BÁO CÁO MÔN NGUYÊN LÝ CNPM

Nội dung trình bày

Demo

Nội dung trình bày

◦ Khái niệm

◦ Baseline

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

◦ Cơ sở dữ liệu quản lý cấu hình

Demo

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

 Trong quá trình phát triển phần mềm, thay đổi

là điều không thể tránh khỏi

data

other documents

Test

Project Plan

changes in technical requirements

changes in business requirements

changes in user requirements

software models

Cần có một cơ chế để quản lý sự thay đổi

trong quá trình phát triển phần mềm

code

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

Software Configuration Management (SCM) là

một quá trình nhận dạng, tổ chức và kiểm soát

những thay đổi trong quá trình phát triển phần

mềm cũng như quản lý những phiên bản khác

nhau của phần mềm đang xây dựng.

 SCM có thể xem như là một phần trong quy trình quản lý chất lượng phần mềm tổng thể và được áp

dụng xuyên suốt trong vòng đời (life cycle) của một

Đơn vị cấu hình phần mềm

 Các output của một quy trình phần mềm

 Tất cả những sản phẩm đó tạo thành cấu hình

phần mềm.

Mỗi sản phẩm được gọi là một đơn vị cấu hình

được quản lý.

data

The pieces

Đơn vị cấu hình phần mềm (2)

 Các đơn vị cấu hình là các thành phần quan

trọng của dự án và có quan hệ mật thiết với

nhau.

 Sự thay đổi của một đơn vị cấu hình sẽ kéo

theo sự thay đổi của một hoặc nhiều đơn vị

cấu hình khác Điều này có thể ảnh hưởng đến thời gian thực hiện, khối lượng công việc cũng như nhân lực cần thiết để hoàn thành dự án.

 Vì vậy, các thay đổi đối với đơn vị cấu hình cần được quản lý và kiểm soát chặt chẽ.

Đơn vị cấu hình phần mềm (3)

Ví dụ về các đơn vị cấu hình và mối quan hệ giữa chúng

với nhau

 Baseline có thể tạm hiểu là cấu hình sản phẩm, đó là

một tập hợp các phiên bản của các đơn vị cấu hình có quan hệ logic chặt chẽ với nhau, tạo thành một trạng thái sản phẩm và được phê duyệt.

 Các baseline có thể chứa một hoặc nhiều đơn vị cấu hình và được đánh số theo Baseline ID

 Các đơn vị cấu hình trong cùng một baseline là tương thích với nhau.

 Những thay đổi đối với các đơn vị cấu hình đã được

baseline đều phải được kiểm soát và thông qua các thủ tục quản lý thay đổi.

 Baseline có thể xem như một cột mốc (milestone) trong

Baseline (2)

 Thời điểm baseline được xác định căn cứ vào các giai đoạn thực hiện dự án.

 Tùy theo thời gian thực hiện, tính chất và quy mô

dự án mà số lượng sản phẩm được baseline khác nhau.

Ví dụ: Baseline Identification

Baseline (3)

Baseline ID Stage

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

 Việc quản lý cấu hình cần được lên kế hoạch trước như là một phần trong kế hoạch quản lý dự án tổng thể

Software Configuration Management Plan

Cơ sở dữ liệu quản lý cấu hình

Tất cả thông tin quản lý cấu hình cần được lưu trữ trong một cơ sở dữ liệu chung

Ngoài việc định nghĩa cấu trúc CSDL, cần xác định cách thức lưu trữ cũng như phân quyền truy xuất thông tin cấu hình phần

mềm

CSDL quản lý cấu hình có thể là một phần trong môi trường tích hợp để hỗ trợ cho

việc phát triển phần mềm

◦ Thư mục kiểm soát (controlled library): được dùng để lưu các

phiên bản của đơn vị cấu hình

◦ Thư mục lưu trữ (static library): được dùng để lưu các cấu hình

(baseline) đã được ban hành

Staff Access right Read Insert Replace Delete

Developer Development library Y Y Y Y

Master library N N N N Archive library N N N N SCM / QA Development library Y Y Y Y

Master library Y Y N N Archive library Y N N N

Nội dung trình bày

Demo

Quy trình quản lý cấu hình PM

Định danh đối tượng

Mỗi đối tượng cấu hình cần được định danh duy nhất

Hai loại đối tượng cần định danh:

◦ Đối tượng cơ sở (basic object): là một đơn vị

sản phẩm được tạo ra trong quá trình phát triển phần mềm

 Ví dụ: Một đoạn trong đặc tả yêu cầu hay một form giao diện, một test case…

◦ Đối tượng tổng hợp (aggregate object): là một

tập hợp các đối tượng cơ sở hoặc những đối

tượng tổng hợp khác

Định danh đối tượng (2)

Mỗi đối tượng có một tập các thuộc tính

phân biệt:

◦ Tên đối tượng (name): là duy nhất

◦ Thông tin mô tả (description)

 Loại đối tượng SCI: là chương trình, tài liệu hay dữ liệu

 Định danh dự án

 Thông tin phiên bản

◦ Tài nguyên của đối tượng (resource): những

thực thể liên quan đến đối tượng

◦ Hiện thực của đối tượng (realization): là một con

trỏ đến đối tượng cơ sở hoặc là con trỏ null đối

với đối tượng tổng hợp

Định danh đối tượng - Ví dụ

Quan hệ thành phần

◦ E-R diagram 1.4 <part-of> data model;

◦ data model <part-of> design specification;

Quan hệ hai chiều

◦ data model <interrelated> data flow model;

◦ data model <interrelated> test case class m;

Quản lý phiên bản

Quản lý phiên bản (Version control) là sự kết

hợp giữa những thủ tục và công cụ nhằm quản

lý những phiên bản khác nhau của các đối

tượng cấu hình được tạo ra trong quá trình

Đối tượng quản lý phiên bản

Định danh phiên bản

 Mỗi phiên bản phần mềm nên được định danh duy nhất

◦ Đánh số phiên bản theo thứ tự tuyến tính

◦ Hỗ trợ việc truy vấn phiên bản

= Jan 2003)

ngữ Java và platform là Linux

◦ Vấn đề phát sinh: có thể bị trùng lắp tên phiên bản

Quản lý thay đổi

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 quản lý thay đổi 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 của

khách hàng, các giai đoạn (phase) trong quy trình phát triển phần mềm từ phân tích thiết kế, đến lập trình, kiểm tra phần mềm đều phải thay đổi theo

Quản lý thay đổi (2)

Nếu các thay đổi này không được kiếm

soát chặt chẽ sẽ dẫn đến rất nhiều sai sót

◦ Xét ví dụ sau: 5 lập trình viên cùng làm trong một

dự án, nhưng chỉ có 3 được thông báo về việc thay đổi thiết kế Kết quả là khi tích hợp, hệ

Quản lý thay đổi (3)

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

Quản lý thay đổi (5)

Trong kiểm soát thay đổi, ta cũng thường

gặp khái niệm “nhóm kiểm soát thay đổi”

gọi tắt là CCB (Change Control Board),

nhóm này được thành lập trong từng dự án CCB thông thường bao gồm:

◦ Trưởng QLCH (Configuration Manager)

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

◦ Trưởng kỹ thuật (Technical Lead)

◦ Trưởng nhóm test (Test Lead)

◦ Kỹ sư chất lượng (Quality Engineer)

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

Quản lý thay đổi (6)

◦ 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, xác nhận các thay đổi

◦ Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng

Quản lý thay đổi (7)

Điền thông tin vào mẫu yêu cầu thay đổi

Phân tích yêu cầu thay đổi

Nếu thay đổi hợp lý thì

Thay đổi như thế nào khi triển khai thay đổi Chi phí cho sự thay đổi

Lưu sự thay đổi vào trong cơ sở dữ liệu.

Gởi yêu cầu đến bộ phận kiểm soát thay đổi.

Nếu thay đổi được chấp nhận thì

Lặp

Thực hiện thay đổi phần mềm Lưu sự thay đổi, kết hợp với các yêu cầu khác Gởi phần mềm đã thay đổi cho bộ phận phê

Quản lý thay đổi (8)

Change Request Form Project: Proteus/PCL-Tools Number: 23/02 Change requester: I Sommerville Date: 1/12/02 Requested change: When a component is selected from the structure, display

the name of the file where it is stored.

Change analyser: G Dean Analysis date: 10/12/02 Components affected: Display-Icon.Select, Display-Icon.Display Associated components: FileTable

Change assessment: Relatively simple to implement as a file name table is

available Requires the design and implementation of a display field No changes

to associated components are required.

Change priority: Low Change implementation:

Estimated effort: 0.5 days Date to CCB: 15/12/02 CCB decision date: 1/2/03 CCB decision: Accept change Change to be implemented in Release 2.1 Change implementor: Date of change:

Date submitted to QA: QA decision:

Date submitted to CM:

Kiểm chứng cấu hình

configuration audit) : bổ sung việc

xem lại hệ thống, những quyết định

cấu các đối tượng tiêu biểu (CI), các đối tượng mà ít liệt kê trong lúc xem lại hệ thống

◦ Kiểm tra các yêu cầu cần thay đổi đã

được thực hiện chưa?

◦ Nội dung cung cấp cho khách hàng có đạt yêu cầu không?

Kiểm chứng cấu hình (2)

Có 3 loại kiểm chứng thường được thực hiện:

Report : kết quả của phase báo cáo tình trạng cấu hình)

 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:

được liệt kê

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ý

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

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

khách hàng yêu cầu có được kiểm tra

chặt chẽ trên sản phẩm tạo ra trước khi giao cho khách hàng hay không Gồm:

 Kiểm tra vết để phản ánh tính 2 chiều giữa yêu cầu khách hàng và việc kiểm tra sản phẩm

Báo cáo tình trạng cấu hình

và báo cáo tình trạng của các CI

(Configuration Items) 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

nhiêu file bị ảnh hưởng khi sữa chữa một lỗi phần mềm nào đó?

Báo cáo tình trạng cấu hình (2)

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

◦ Liệt kê tất cả baseline và CI thành phần hoặc có liên quan

◦ Làm nổi bật các Cl đang được phát triển hoặc vừa bị thay đổi

◦ Liệt kê các thay đổi còn đang dang dở hay đang hoàn thành, và các baseline bị ảnh hưởng (bởi

sự thay đổi đó)

Kết luận

trọng đối với hệ thống.

hoạch, chi phí, thời gian, tầm ảnh

hưởng, tính khả thi, bảo hành bảo trì.

Phụ lục

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

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

◦ CM (Configuration manager)

 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 QLCH của dự án

 Thiết lập các baseline, ghi nhận chi tiết 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

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

 Giám sát các hoạt động QLCH

 Bảo đảm các yêu cầu cần thiết cho hoạt động QLCH Ví dụ: số giờ thành viên dự

án bỏ ra cho QLCH, công cụ hỗ trợ cho QLCH

◦ CCB (Configuration Control Board)

 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, xác nhận các thay đổi

 Phê chuẩn các bản phân phối sản phẩm (release) đến khách hàng

◦ 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ủ tất cả các quy trình thủ tục của bản kế hoạch QLCH (CMP)

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

Nội dung trình bày

Demo

Case tools cho quản lý cấu hình

 Một số case tool thông dụng:

◦ Visual SourceSafe: công cụ quản lý cấu hình quen thuộc,

gắn với Visual Studio phiên bản 2005 trở về trước

◦ Team Foundation Version Control: thay thế cho VSS,

thuộc nền tảng quản lý làm việc nhóm Team Foundation

Server của Micorsoft, gắn với Visual Studio 2008

◦ Concurrent Versions System (CVS): công cụ quản lý

cấu hình open source đã từng rất nổi tiếng nhưng hiện

không còn thông dụng.

◦ Subversion (SVN): công cụ quản lý cấu hình open source

ra đời với mục đích thay thế cho CVS, hiện đang được sử dụng rất rộng rãi Bao gồm nhiều phiên bản client:

 Tortoise SVN (Windows)

 VisualSVN (tích hợp SVN vào Visual Studio)

 Subclipse (Eclipse)

Bảng so sánh SCM Case tools

maintained but new features not

GPL Unix-like, Windows, Mac

SVN CollabNet, Inc. actively developed Client-server Lock or merge Apache/BSD style

Unix-like, Windows, Mac

OS X

Free (Commercial support/service

s available)

Visual

SourceSafe Microsoft serious bug fixes only Client-server Lock or merge Proprietary Windows

~$500 per license or single license included with each MSDN subscription.

Clients:

Windows and Web included

Licensed through MSDN subscription or through direct buy

Bảng so sánh SCM Case tools (2)

Software Atomic commits File renames Merge file renames Symbolic links

event hooks Signed revisions Merge tracking Tags International Support

để quản lý phiên bản phần mềm:

◦ Tạo project và add vào repository

◦ Quản lý, phục hồi phiên bản

Xin cám ơn sự theo dõi của Thầy và

các Anh Chị!