Bài giảng Công nghệ phần mềm - Chương 5: Quản lý cấu hình phần mềm - Phạm Đào Minh Vũ

Nội dung text: Bài giảng Công nghệ phần mềm - Chương 5: Quản lý cấu hình phần mềm - Phạm Đào Minh Vũ

1. CHƢƠNG 5. QUẢN LÝ CẤU HÌNH PHẦN MỀM (SOFTWARE CONFIGURATION MANAGEMENT) 197
2. Nội dung 1. Tổng quan về phần mềm 2. Hoạch định quản lý cấu hình 3. Quản lý sự thay đổi phần mềm 4. Quản lý phiên bản 5. Tích hợp hệ thống từ các thành tố 198
3. Khái niệm  Quản lý cấu hình (software configuration management - SCM):  Là tiến trình kiểm soát, theo vết các thay đổi của một hệ thống phần mềm  Được dùng để quản lý các phiên bản khác nhau của phần mềm đó  «Mục đích của QLCH là để thiết lập và bảo đảm tính toàn vẹn của các sản phẩm trung gian cũng như các sản phẩm sau cùng của một dự án phần mềm, xuyên suốt chu kỳ sống của dự án đó» – trích từ CMMI và ISO 15504 199
4. Mối liên hệ giữa QLCH và QLCL Đội ngũ Yêu cầu Sản phẩm Đội ngũ phát triển PM PM kiểm soát PM chất lượng Sản phẩm PM Sản phẩm PM Đội ngũ kiểm soát Các ghi nhận cấu hình Các báo cáo về thay đổi so về kiểm soát với phiên bản chất lượng trước PM 200
5. Tại sao cần quản lý cấu hình ? Một chức năng Một lỗi (bug) nào đó (function) nào đó của của phần mềm đang phần mềm đã được xây dựng đã tốn nhiều phát triển và kiểm tra công sức sửa chữa, cẩn thận bổng thất lạc bỗng “thình lình” xuất hoặc biến mất một cách hiện trở lại khó hiểu Một chương trình Làm sao có thể (program) đã tích hợp hệ thống được kiểm tra hết sức cẩn thận, và biên dịch, trong bỗng nhiên hàng chục tập tin không “chạy” source code với được nữa hàng trăm version 201
6. Tại sao cần quản lý cấu hình ? (tt) . Phần mềm chạy trên nhiều họ máy tính khác nhau . Phần mềm chạy trên nhiều hệ điều hành khác nhau . Gồm các chức năng được phát triển cho một nhóm khách hàng cụ thể . Sử dụng đa ngôn ngữ Cần phải sử dụng cây quản lý cấu hình phần mềm Chức năng cây quản lý cấu hình:  Theo dõi và quản lý sự khác nhau giữa các phiên bản  Đảm bảo các phiên bản mới được bắt nguồn (kế thừa) từ phiên bản gốc trong một tiến trình đƣợc kiểm soát (không được tùy tiện, tự phát)  Đảm bảo các phiên bản mới được giao đến đúng khách hàng và đúng thời gian quy định 202
7. Sơ đồ minh họa cây QLCH Phiên bản cho máy chủ Phiên bản cho Phiên bản HP Vindow Phiên bản Phiên Hệ thống cho máy để bản cho khởi đầu bàn máy PC Phiên bản UNIX Phiên bản SUN 203
8. Chuẩn về quản lý cấu hình ? . Trong mỗi tổ chức sản xuất phần mềm, những quy định chung về quản lý cấu hình được công bố trong “sổ tay quản lý cấu hình” hoặc “cẩm bang bảo đảm chất lượng phần mềm”. Các quy định này có thể xuất phát từ các chuẩn tổng quát như: IEEE 828-1983, ISO 9000, CMMI, . Một số chuẩn về quản lý cấu hình được phát triển theo qui ước mô hình thác nước được dùng để phát triển hệ thống. Do đó, không thể áp dụng hiệu quả cho các tiếp cận phát triển phần mềm theo các mô hình chu kỳ sống tiến hóa 204
9. Các hoạt động trong tiến trình QLCH . Bao gồm 4 hoạt động chính (tiến trình con) sau đây: 1. Hoạch định quản lý cấu hình 2. Quản lý sự thay đổi phần mềm 3. Quản lý phiên bản của phần mềm 4. Xây dựng phần mềm từ các thành tố Lưu ý: . Tiến trình quản lý cấu hình chỉ thực sự chạy sau khi một phiên bản đầu của hệ thống được phát triển . Tuy nhiên, một số đề xuất hoạch định tiến trình nên bắt đầu ngay khi khởi động đề án và hoạt động suốt thời gian phát triển hệ thống 205
10. Các thông tin trong phƣơng án QLCH  Định nghĩa các thực thể (dùng cho HĐH nào? Dành cho loại máy nào? Các lỗi đã được fix ? Các cải tiến mới, ) được quản lý và đưa ra cách thức chặt chẽ để nhận ra các thực thể này  Quy định người chịu trách nhiệm về các thủ tục quản lý cấu hình và trình bày giải thích các thực thể được quản lý trước đội ngũ quản lý cấu hình  Các phương pháp dùng để quản lý phiên bản và kiểm soát thay đổi  Mô tả CSDL dùng để ghi thông tin cấu hình  Các thông tin khác: quản lý các phần mềm được sử dụng cho đề án, quản lý thủ tục kiểm tra tiến trình quản lý cấu hình, 206
11. Các đối tƣợng cấu hình đƣợc quản lý  Đặc tả hệ thống  Kế hoạch dự án phần mềm  Đặc tả yêu cầu  Đặc tả yêu cầu phần mềm  Nguyên mẫu thi hành được hoặc nguyên mẫu giấy tờ  Sổ tay sử dụng sơ cấp  Các đặc tả thiết kế  Dữ liệu  Kiến trúc  Module  Giao diện  Đối tượng (hướng đối tượng) 207
12. Các đối tƣợng cấu hình đƣợc quản lý (tt)  Mã nguồn và kiểm thử  Kế hoạch và thủ tục kiểm thử  Các ca kiểm thử và các kết quả được ghi lại  Các sổ tay vận hành và sổ tay lắp đặt  Chương trình thi hành được  Các module và mã thi hành được  Các module đã liên kết  Bộ dữ liệu thử nghiệm  Mô tả cơ sở dữ liệu  Lược đồ và cấu trúc các file  Nội dung hồ sơ ban đầu 208
13. Các đối tƣợng cấu hình đƣợc quản lý (tt)  Sổ tay người sử dụng  Các tài liệu bảo trì  Các báo cáo những vấn đề phần mềm  Các yêu cầu bảo trì  Đặt tả thay đổi kỹ nghệ  Các chuẩn và các thủ tục cho kỹ nghệ phần mềm 209
14. Các đối tƣợng cấu hình đƣợc quản lý (tt)  Đặt tên các đối tượng cấu hình: cần đảm bảo các điều kiện sau:  Một đối tượng phải có một tên duy nhất trong toàn bộ hệ thống quản lý cấu hình  Tên đối tượng nên xúc tích, gợi nhớ và bao hàm ý nghĩa của đối tượng  Cách đặt tên hàm ý các mối liên hệ giữa các đối tượng được quản lý (như mối quan hệ giữa văn bản thiết kế và mã nguồn của một phiên bản nào đó cho bản thiết kế đó)  Bản thân phương pháp đặt tên đối tượng phải được kiểm soát bởi hệ thống cấu hình (tự động hoặc không), không được tùy ý đặt tên 210
15. CSDL dùng để quản lý cấu hình  Ghi tất cả các thông tin liên quan quản lý cấu hình  Các chức năng chính:  Theo dõi  Kiểm soát từ thay đổi  Cung cấp các thông tin quản lý  Các tác vụ của tiến trình hoạch định QLCH liên quan đến khía cạnh CSDL gồm:  Định nghĩa lược đồ CSDL  Định nghĩa các thủ tục quản lý thông tin  Định nghĩa các thủ tục truy xuất thông tin  Các CSDL có thể được cài đặt tích hợp hoặc riêng lẻ  Các câu truy vấn thông thường : 6 câu 211
16. CSDL dùng để quản lý cấu hình (tt) Các câu truy vấn thƣờng dùng: 1. Có bao nhiêu khách hàng sử dụng một phiên bản cụ thể của phần mềm ? 2. Phải dùng cấu hình HĐH và phần cứng nào để chạy một phiên bản của một phần mềm đã cho ? 3. Một phần mềm nào đó có bao nhiêu phiên bản và được tạo lập vào những ngày nào ? 4. Những phiên bản nào của một phần mềm bị ảnh hưởng nếu thay đổi một thành tố cụ thể nào đó ? 5. Có bao nhiêu yêu cầu thay đổi phần mềm còn tồn đọng đối với một phiên bản cụ thể ? 6. Có bao nhiêu lỗi đã được ghi nhận cho một phiên bản cụ thể của phần mềm ? 212
17. Tiến trình Tiến trình quản lý sự thay đổi phần mềm bao gồm:  Phân tích sự đánh giá về mặt kỹ thuật  Đánh giá chi phí  Theo dõi “vết” của thay đổi 213
18. Mô tả thuật toán của tiến trình quản lý sự thay đổi phần mềm Yêu cầu thay đổi bằng cách điền vào “mẫu yêu cầu thay đổi” Phân tích các yêu cầu thay đổi Nếu thì { Đánh giá sơ bộ cách thức cài đặt các thay đổi Ước lượng phí tổn Ghi nhận các yêu cầu thay đổi vào CSDL Đệ trình yêu cầu thay đổi tới Bộ phận kiểm soát thay đổi Nếu thay đổi được chấp nhận thì { lặp lại { tiến hành phần mềm thay đổi theo yêu cầu Ghi nhận thay đổi, liên kết với yêu cầu thay đổi Đệ trình phần mềm để phê chuẩn chất lượng } đến khi (chất lượng phần mềm có thể chấp nhận) Tạo phiên bản mới } Ngược lại Bác bỏ yêu cầu thay đổi } Ngược lại Bác bỏ yêu cầu thay đổi 214
19. Các quy định chung trong QLCH  Trừ các thay đổi đơn giản, việc thay đổi phần mềm nên đệ trình lên bộ phận kiểm soát thay đổi để phê duyệt  Bộ phận kiểm soát thay đổi xem xét tác động của việc thay đổi theo nhiều quan điểm thay vì chỉ dựa theo quan điểm kỹ thuật  Bộ phận kiểm soát thay đổi bao gồm: một nhóm các thành viên có thể đưa ra các quyết định thay đổi phần mềm  Quy mô và cấu trúc của bộ phận này có thể thay đổi tùy thuộc vào đề án: . Với đề án lớn: có thể bao gồm cả khách hàng lâu năm và hội đồng thầu khoán . Với đề án nhỏ/vừa: gồm người quản lý đề án và 1 hay 2 kỹ sư không tham gia trực tiếp vào việc phát triển đề án 215
20. Theo dõi sự thay đổi của mỗi thành tố trong một hệ thống phần mềm  Ghi nhận thông tin lịch sử của mỗi thành tố phần mềm  Các quy ước về ghi nhận thông tin thay đổi  Hỗ trợ của công cụ tin học:  Các môi trường quản lý cấu hình thường tích hợp hệ thống quản lý phiên bản và hệ thống theo dõi thay đổi phần mềm nhờ vào hệ thống thư điện tử  Các môi trường mô phỏng tiến trình hay hệ thống luồng công việc. Tiến trình thay đổi phần mềm được mô phỏng thành các mô hình tiến trình và động cơ thông dịch để trình diễn tiến trình 216
21. Khái niệm Quản lý phiên bản là tiến trình định nghĩa, theo dõi và kiểm soát các phiên bản khác nhau của một hệ thống phần mềm Phiên bản (version): là một thể hiện của phần mềm mà có sự thay đổi so với các thể hiện khác của phần mềm đó . Thay đổi có thể bao gồm: chức năng mới, cải tiến hiệu năng, sửa đổi lỗi của phiên bản cũ Một số phiên bản có thể tương đương hoàn toàn về mặt chức năng nhưng được thiết kế để hoạt động cho các cấu hình phần mềm hay phần cứng khác nhau 217
22. Khái niệm (tt)  Phiên bản phát hành (release): là một phiên bản được phân phối đến khách hàng. Số lượng phiên bản của một hệ thống phần mềm nhiều hơn số lượng phiên bản phát hành hệ thống đó  Cấu trúc tổng quát của một phiên bản phát hành bao gồm: . Các chương trình thực thi hay một tập hợp các chương trình . Các tập tin cấu hình để xác định cách thức, nghi thức cài đặt cho từng môi trường cụ thể . Các tập tin dữ liệu cần cho sự hoạt động của hệ thống . Một chương trình cài đặt dùng để cài đặt hệ thống phần mềm . Các tài liệu (giấy/văn bản điện tử) liên quan đến hệ thống phần mềm 218
23. Khái niệm (tt) Khi một phiên bản phát hành được sản xuất, tổ chức sản xuất phần mềm cần phải:  Ghi nhận lại các thông tin về công cụ và môi trường cần thiết để xây dựng phần mềm, chẳng hạn thông tin về hệ điều hành, các trình biên dịch, các công cụ hỗ trợ,  Để có thể xây dựng lại phiên bản này, cần tái lập lại chính xác môi trường cấu hình. Trong một số trường hợp, hệ thống quản lý phiên bản có thể chép lưu trữ các phần mềm cơ sở và các công cụ trợ giúp đã dùng để phát triển phiên bản này 219
24. Xác định và định danh phiên bản Có 3 phương pháp chính:  Sơ đồ tuyến tính  Sơ đồ định danh theo dạng mạng  Sơ đồ định danh theo tên 220
25. 1. Sơ đồ tuyến tính Sơ đồ này giả sử sự tiến hóa của hệ thống phần mềm diễn ra tuần tự, phiên bản sau tương thích với phiên bản trước:  Phiên bản đầu tiên là 1.0  Các phiên bản cơ sở là 1.0, 2.0, 3.0,  Các phiên bản khác bắt nguồn từ phiên bản cơ sở, như: 2.1, 2.1.1, 3.0.1,  Khó khăn:  Nếu nhiều phiên bản bắt nguồn từ phiên bản cha thì đánh số phiên bản như thế nào ?  Nếu nhiều phiên bản của hệ thống được tạo ra và phân phối đến nhiều khách hàng khác nhau, mỗi khách hàng có một phiên bản duy nhất thì định danh thế nào? 221
26. 2. Sơ đồ định danh theo dạng mạng V 1.0 V 1.1b V 1.1.1 V 1.1 V 1.2 V 2.0 V 2.1 V 2.2 V 1.1a  Phiên bản 1.0 được phát triển theo 2 hướng khác nhau để thành 1.1 và 1.1a. Sau đó, 1.1 được phát triển thành 1.2 và 1.1b  Phiên bản 2.0 không được phát triển từ 1.2 mà trực tiếp từ 1.1a. Phiên bản 2.2 không được phát triển từ 2.0 mà từ 1.2 222
27. 3. Sơ đồ định danh theo tên  Là việc sử dụng tên hoặc ký hiệu để định danh cho phiên bản. Ví dụ: V1/VMS/DBServer là phiên bản của DB server chạy trên hệ điều hành VMS Lƣu ý chung về việc định danh phiên bản: Các phương pháp định danh phiên bản đều không phản ánh hết các thuộc tính liên quan đến mỗi phiên bản phần mềm. Các thuộc tính nên được lưu trong CSDL quản lý cấu hình và bao gồm ít nhất là các thông tin sau:  Khách hàng  Ngôn ngữ dùng để phát triển  Tình trạng phát triển  Cấu hình phần cứng  Hệ điệu hành  Ngày tạo phiên bản 223
28. Quản lý phiên bản phát hành Các hoạt động liên quan đến quản lý phiên bản phát hành khi cho ra đời một phiên bản mới:  Bổ xung thêm mã nguồn  Xây dựng lại hệ thống  Chuẩn bị các tập tin cấu hình  Soạn tài liệu mới  Đóng gói và phân phối đến khách hàng Các thay đổi dẫn đến phát hành phiên bản mới:  Để khắc phục lỗi  Để hoàn thiện phần mềm  Để phù hợp với môi trường mới 224
29. Quản lý phiên bản phát hành (tt) Chú ý: . Không nên thực hiện đồng thời nhiều dạng thay đổi cho cùng một phiên bản . Ưu tiên cho việc khắc phục các lỗi trầm trọng . Có thể thực hiện chiến lược luân phiên để cải tiến các phiên bản phát hành Phiên bản Phiên bản Phiên bản Phiên bản được khắc được cải được khắc được cải phục lỗi tiến phục lỗi tiến khác 225
30. Công cụ trợ giúp quản lý phiên bản  Một số công cụ thông dụng: Visual Source Safe của Microsoft, ClearCase của Rational, CVS (nguồn mở).  Các chức năng chính: 1. Định danh phiên bản: có thể định danh tự động và định nghĩa các thuộc tính cho mỗi phiên bản 2. Kiểm soát thay đổi: ghi nhận tường minh các thành tố bị thay đổi, người đã thực hiện sự thay đổi, lưu phiên bản cũ trước đó 3. Quản lý không gian lưu trữ: tiết kiệm kích thước không gian lưu trữ 4. Ghi nhận “vết”, lịch sử của việc thay đổi phiên bản 226
31. Công cụ trợ giúp quản lý phiên bản (tt) Để tiết kiệm không gian lưu trữ, một số hệ thống thực hiện như sau: 1. Ghi nhận lại một phiên bản chính 2. Ghi nhận lại sự thay đổi giữa các phiên bản (gọi là Delta, kích thước Delta nên nhỏ hơn nhiều so với kích thước mỗi phiên bản) V 1.0 V 1.1 V 1.2 V 1.3 D1 D2 D3 227
32. Khái niệm Là tiến trình tổ hợp các thành tố của hệ thống thành một chương trình có thể thực hiện trên một môi trường có cấu hình cụ thể Đối với hệ thống lớn, đây là một tiến trình đóng vai trò quan trọng trong quản lý cấu hình Các yếu tố phải xem xét: a) Đã xác định đầy đủ các thành tố cần để tích hợp hệ thống hay chưa? b) Đã có phiên bản thích hợp của mỗi thành tố hay chưa? c) Các tập tin dữ liệu cần thiết đã có sẵn hay chưa? 228
33. Khái niệm d) Vấn đề trùng tên tập tin giữa các tập tin trong hệ thống đang phát triển và các tập tin có sẵn ở môi trường mà hệ thống sẽ hoạt động e) Đã có sẵn các phiên bản của trình biên dịch và các công cụ cần thiết chưa? Sự tương thích của trình biên dịch và các công cụ với các thành tố của hệ thống đang tích hợp  Thời gian dịch và nối kết: Với các hệ thống lớn, thời gian dịch và nối kết có thể kéo dài hàng giờ, hàng ngày cho mỗi chỉ thị dịch và nối kết. Để cải tiến về thời gian thông thường người ta thực hiện: d) Ghi nhận các thành tố đã được dịch hoàn tất và biết được các sửa đổi nào không ảnh hưởng đến chúng e) Cung cấp một ngôn ngữ để mô tả việc tích hợp các thành tố, việc mô tả phải hàm ý được các thành tố không cần xây dựng lại 229
34. Ví dụ: lệnh MAKE của UNIX dựa trên mô tả phụ thuộc để không cần dịch lại các thành tố đã biên dịch Mô tả các thành tố và các phụ thuộc giữa các thành tố Hệ thống đã Các tập tin chứa các MAKE thành tố tích hợp Các chương trình dịch và nối kết 230
35. Công cụ hỗ trợ Các công cụ hỗ trợ việc tích hợp hệ thống:  Trên PC có sẵn các môi trường tích hợp hệ thống đang phát triển với các chức năng rất tiện dụng và dễ dàng sử dụng cho người phát triển phần mềm  Tuy nhiên chưa giải quyết được việc quản lý phiên bản cho mỗi thành tố và chưa theo dõi được vết của sự thay đổi các thành tố 231