Tiểu luận quản lý cấu hình phần mềm

Chia sẻ: Trinh Van Chien | Ngày: | Loại File: DOC | Số trang:23

0
306
lượt xem
136
download

Tiểu luận quản lý cấu hình phần mềm

Mô tả tài liệu
  Download Vui lòng tải xuống để xem tài liệu đầy đủ

Trong quá trình phát triển các hệ thống thông tin, rất hiếm khi không có thay đổi. Người dùng thường xuyên quên mất các yêu cầu và chỉ nhớ đến chúng sau này trong khi tiếp nhận bản thiết kế. Không những thế, sự thay đổi còn xảy ra ngay trong các giai đoạn phát triển ứng dụng. Sự thay đổi có thể được hình thành cho yêu cầu từ phía người dùng thay đổi, các bản thiết kế có sự điều chỉnh....

Chủ đề:
Lưu

Nội dung Text: Tiểu luận quản lý cấu hình phần mềm

  1. TRƯỜNG ĐẠI HỌC HẢI PHÒNG ---  --- Giảng viên: …………………… Sinh viên : 1. Trịnh Văn Chiến ( T ) 2. Nguyễn Văn Tùng A 3. Cao Thăng Long 4. Trần Văn Tuấn 5. Trần Quyết Cường Lớp học Cử Nhân Tin K8 BÁO CÁO CÔNG NGHỆ PHẦN MỀM Hải Phòng, tháng 08 năm 2006 Đề TàI QUảN Lý CấU HìNH PHầN MềM Hải Phòng, tháng 9 năm 2010 0
  2. Mục lục Trang 1. Quản lý cấu hình phần mềm (Configuration Management) ............................... 2 1.1 Quản lý cấu hình phần mềm là gì? .................................................................... 2 1.2 Nội dung của quản lý cấu hình phần mềm ........................................................ 2 1.3 Nhiệm vụ của quản lý cấu hình......................................................................... 4 1.4 Lợi ích của việc quản lý cấu hình phần mềm .................................................... 4 2. Xác định cấu hình phần mềm. .............................................................................. 5 3. Kiểm soát phiên bản .............................................................................................. 6 4. Kiểm soát thay đổi ................................................................................................. 7 4.1 Qui trình kiểm soát sự thay đổi ......................................................................... 8 4.2 Các hoạt động kiểm soát sự thay đổi................................................................. 9 5. Kiểm toán cấu hình phần mềm ........................................................................... 11 5.1 Rà soát kỹ thuật chính thức............................................................................. 11 5.2 Kiểm toán cấu hình phần mềm ....................................................................... 11 6. Báo cáo hiện trạng ............................................................................................... 12 7. Một số công cụ tự động hỗ trợ quản lý cấu hình và quản lý thay đổi ............... 12 7.1 Công cụ hỗ trợ cho sự cộng tác (Collaborative Work Tools) .......................... 12 7.2 Công cụ hỗ trợ về tài liệu (Documentation Tools) .......................................... 13 7.3 Công cụ đối chiếu thiết kế phần mềm (Tools for Reverse Engineering of Software) 14 7.4 Công cụ quản lý cấu hình (Tools for Configuration Management) ............... 15 8. Vài nét về USDP (Unified Software Development Process).................................. 15 8.1 Giới thiệu chung ........................................................................................... 15 8.2 Lịch sử phát triển ......................................................................................... 15 8.3 Kiến trúc tổng quát của RUP ....................................................................... 16 Tài liệu tham khảo................................................................................................... 18 1
  3. QUẢN LÝ CẤU HÌNH PHẦN MỀM CONFIGURATION MANAGEMENT Trong quá trình phát triển các hệ thống thông tin, rất hiếm khi không có thay đổi. Người dùng thường xuyên quên mất các yêu cầu và chỉ nhớ đến chúng sau này trong khi tiếp nhận bản thiết kế. Không những thế, sự thay đổi còn xảy ra ngay trong các giai đoạn phát triển ứng dụng. Sự thay đổi có thể được hình thành cho yêu cầu từ phía người dùng thay đổi, các bản thiết kế có sự điều chỉnh. Chính sự điều chỉnh này làm thay đổi qui trình mã hoá và sửa lỗi, những thay đổi đó cần được lưu lại để người phát triển có thể quản lý được sự tiến hoá của phần mềm. Sự thay đổi là một trong nhiều lý do khiến cho các dự án đi đến thất bại. Nhưng hiện nay thực sự chưa phương pháp hiệu quả để hạn chế sự thay đổi và người phát triển hệ thống phần mềm coi quản lý sự thay đổi đó là một phần trong qui trình quản lý dự án phần mềm. Qui trình quản lý đó được gọi là quản lý cấu hình phần mềm. 1. Quản lý cấu hình phần mềm (Configuration Management) 1.1 Quản lý cấu hình phần mềm là gì? Quản lý cấu hình phần mềm là tập hợp các hoạt động dùng để quản lý các thay đổi của phần mềm trong suốt vòng đời của phần mềm. Chúng ta cũng cần phân biệt giữa quản lý cấu hình phần mềm và bảo trì phần mềm. Bảo trì phần mềm là các hoạt động được thực hiện sau khi phần mềm đi vào hoạt động. Còn quản lý cấu hình phần mềm là hoạt động bao trùm suốt quá trình phát triển phần mềm thông qua việc theo dõi, kiểm soát phần mềm từ khi bắt đầu phát triển đến khi phần mềm không còn hoạt động nữa. Quản lý cấu hình phần mềm được xem là một hoạt động nhằm đảm bảo chất lượng phần mềm. Vì thông qua các báo cáo liên quan đến sự thay đổi có thể lượng hoá và đánh giá được qui trình và chất lượng của cả hệ thống phần mềm được xây dựng. 1.2 Nội dung của quản lý cấu hình phần mềm Nội dung của quản lý cấu hình phần mềm là:  Xác định được những thay đổi diễn ra trong quá trình phát triển.  Kiểm soát được các thay đổi xuất hiện  Đảm bảo các thay đổi xuất hiện đã được thực hiện sửa đổi. 2
  4.  Báo cáo các kết quả của việc sửa đổi được ghi nhận và gửi đến những người có trách nhiệm quản lý và xác minh lại sự thay đổi đó. Quản lý cấu hình phần mềm được thể hiện thông qua các khoản mục sau:  Đặc tả hệ thống: bao gồm các tài liệu thu nhận được sau khảo sát, các bước phân tích đánh giá tài liệu và đưa ra những phác hoạ trong hệ thống dự kiến sẽ xây dựng. Các đặc tả này thường bao gồm những qui trình nghiệp vụ, nội dung thông tin cần mà phần mềm cần xử lý.  Kế hoạch dự án phần mềm: là tài liệu phân chia khối lượng công việc và hoạch định thời gian và tiến trình các công việc đó.  Đặc tả yêu cầu: thể hiện những yêu cầu liên quan đến phần mềm, những công việc mà phần mềm sẽ phải đáp ứng sau khi hoàn thành.  Đặc tả thiết kế: - Đặc tả thiết kế dữ liệu - Đặc tả thiết kế kiến trúc - Đặc tả thiết kế môđun - Đặc tả thiết kế giao diện  Đặc tả mã nguồn và kiểm thử phần mềm: - Kế hoạch và thủ tục kiểm thử - Các ca kiểm thử và các kết quả kiểm thử - Sổ tay vận hành và sổ tay lắp đặt - Chương trình thi hành - Các môđun và mã thi hành được - Các môđun đã liên kết được  Đặc tả cơ sở dữ liệu: - Lược đồ và cấu trúc các file. - Nội dung hồ sơ ban đầu.  Tài liệu bảo trì: - Các tài liệu liên quan đến công tác bảo trì phần mềm. 3
  5. 1.3 Nhiệm vụ của quản lý cấu hình Hình 1: Nhiệm vụ của quản lý cấu hình  Xác định cấu hình phần mềm.  Kiểm soát phiên bản phần mềm  Kiểm soát thay đổi.  Kiểm toán cấu hình phần mềm  Thiết lập các báo cáo liên quan đến những thay đổi trong phần mềm. Việc quản lý cấu hình cần phải trả lời được các câu hỏi sau:  Làm thế nào để tổ chức và quản lý được nhiều phiên bản (Version) của phần mềm sao cho những thay đổi đem lại sự hiệu quả?  Làm sao để tổ chức kiểm soát toàn bộ thay đổi trước và sau khi giao phần mềm cho người sử dụng?  Ai sẽ chịu trách nhiệm về việc chấp thuận và thiết lập thứ tự ưu tiên cho các thay đổi khi có nhiều thay đổi cùng được đề xuất?  Làm thế nào đảm bảo được việc thay đổi đã thực hiện đúng?  Dùng cơ chế nào để đánh giá các thay đổi khác nhau? Trên một diện hẹp thì quản lý cấu hình phần mềm còn được coi là quản lý mã nguồn (Source Code). 1.4 Lợi ích của việc quản lý cấu hình phần mềm 4
  6. Công việc quản lý cấu hình phần mềm đem lại những ích lợi sau:  Cung cấp cho người phát triển phiên bản mới nhất của phần mềm  Quản lý được các mã nguồn được lưu trữ phân tán  Quản lý được các phiên bản khác nhau của phần mềm  Ghi chú lý do của sự thay đổi mã nguồn phần mềm và nội dung thay đổi đó như thế nào.  Tạo sự dễ dàng cho phép người phát triển có thể truy cập lại các phiên bản cũ trước đó thông qua hồ sơ hay các báo cáo được thiết lập,  Giúp tích kiệm được không gian đĩa do không phải cùng một lúc lưu trữ nhiều phiên bản khác nhau trong giai đoạn phát triển.  Cung cấp việc truy cập an toàn và đơn giản đối với bản copy tổng thể về các kết quả bàn giao đã được thông qua.  Kiểm soát được thực trạng của các kết quả bàn giao và mối quan hệ qua lại lẫn nhau giữa các kết quả này.  Cung cấp một kho chứa an toàn đối với các kết quả bàn giao.  Cho phép việc kiểm soát và tiết lộ có nguyên tắc các kết quả bàn giao thông qua vòng đời của nó, với đầy đủ các dấu tích lịch sử, đảm bảo phiên bản đúng và cập nhật, đã được kiểm tra và phát hành  Kiểm soát thay đổi cuả các kết quả bàn giao, đảm bảo các kết quả này được lưu theo đúng thứ tự .  Cung cấp việc lập báo cáo về hiện trạng của các kết quả bàn giao và những thay đổi của chúng. 2. Xác định cấu hình phần mềm. Xác định cấu hình phần mềm là quá trình thiết lập các đối tượng và đặt tên cho các đối tượng trong qui trình phát triển phần mềm. Cần đặt tên không trùng lặp cho các khoản mục trong cấu hình phần mềm để kiểm soát quản lý và tổ chức lại theo phương pháp hướng đối tượng. 5
  7. Xác định cấu hình phần mềm chia thành hai loại đối tượng:  Đối tượng cơ bản: là một “đơn vị văn bản” được kỹ sư phần mềm tạo ra trong quá trình phân tích, thiết kế, lập mã và kiểm thử.  Đối tượng hỗn hợp: được cấu thành từ các đối tượng cơ bản. Mỗi đối tượng có một bộ các đặc tính mà thể hiện của nó là duy nhất phân biệt với các đối tượng khác gồm:  Tên đối tượng: dùng để định danh và đại diện cho đối tượng.  Mô tả đối tượng phần mềm bằng một danh sách các khoản mục, dữ liệu liên quan đến đối tượng: - Kiểu khoản mục cấu hình phần mềm: là tài liệu, chương trình hay dữ liệu. - Chứng thư dự án: xác định vị trí của đối tượng nằm trong giai đoạn nào, phần nào của dự án tổng thể. - Thông tin thay đổi hay thông tin liên quan đến phiên bản.  Danh sách các nguồn lực: là tất cả các thực thể được cung cấp, xử lý, tham khảo và các thức khác mà đối tượng cần đến.  Mối quan hệ giữa các đối tượng là quan hệ bộ phần hay toàn bộ, thể hiện thông qua đồ thị các đối tượng. Các mối quan hệ khác tương tác giữa các đối tượng. Để kiểm soát thay đổi của các đối tượng ta sử dụng đồ thị tiến hoá cho từng đối tượng. Đồ thị tiến hoá mô tả lịch sử đổi thay của đối tượng đó. 3. Kiểm soát phiên bản Trước hết, chúng ta cần tìm hiểu thế nào là phiên bản? Phiên bản (Version) là một thực thể mới của một đối tượng cấu hình (CI: Configuration Item) sau khi đã qua một hoặc nhiều lần xem xét và thay đổi. Kiểm soát phiên bản là tổ hợp các thủ tục và các công cụ để quản lý các phiên bản khác nhau của các đối tượng cấu hình đã được tạo ra trong qui trình xây dựng phần mềm. 6
  8. Quản lý cấu hình cho phép đặc tả cấu hình thay thế của hệ thống phần mềm thông qua những phản hồi của người dùng khi đưa ra những mong muốn mới liên quan đến phần mềm. Để xây dựng một biến thể mới cho phần mềm và xác lập những thay đổi so với các phần mềm trước đó người ta gắn mỗi phiên bản phần mềm với một số đặc điểm đặc trưng cho nó hay còn gọi là một “bộ thuộc tính”. Một phiên bản phần mềm mới được xây dựng khi các đặc trưng của phần mềm trước đó đã không còn đáp ứng được nhu cầu mới của sự phát triển, và sự thay đổi đó là đáng kể về mặt công nghệ. Phiên bản Delta: Delta có nghĩa là sự khác biệt. Một file Delta là một file thể hiện sự khác biệt giữa các phiên bản của một phần mềm. Các phiên bản là các bản sao của một chương trình biểu diễn các thay đổi dần dần. Khi một phiên bản Delta được giữ lại thể hiện rằng chương trình logic chính được thay đổi một lần. Sau đó, phiên bản Delta được ứng dụng trên phiên bản chính với những thay đổi đã được thực hiện ta sẽ thu được các phiên bản Delta. Phiên bản Alpha: là các phiên bản phần mềm đầu tiên được đưa cho các đối tác có kinh nghiệm thử nghiệm. Các đối tác ở đây là một lớp người dùng nhỏ, có kinh nghiệm trong việc triển khai hệ thống. Thông tin được phản hồi là các lỗi được phát hiện, các góp ý liên quan đến việc cải thiện chất lượng phần mềm. Phiên bản Beta: Sau khi khắc phục các thiếu xót trong các phiên bản Alpha, phm đã trở nên hoàn thiện hơn và được tung ra cho lớp người dùng rộng hơn để có thể thu nhận được nhiều ý kiến đóng góp từ mọi ngành nghề, mọi đối tượng có mục đích và yêu cầu khác nhau. Hình 2: Sơ đồ kiểm soát phiên bản 7
  9. Các phiên bản được phân biệt thông qua các con số đi kèm theo sau tên của phần mềm. Ví dụ một số phiên bản của phần mềm Total Commander: Total Commander 5.0; Total Commander 5.25; Total Commander 6.0; Total Commander 6.3. Ở đây, chúng ta thấy sự khác biệt trong tên gọi các phiên bản là các con số đi kèm, khoảng cách giữa các số thường thể hiện sự cải tiến trong phần mềm. Các con số ở hàng đầu tiên chỉ khi các tính năng của phần mềm được thay đổi cơ bản, còn các thông số sau chỉ sự cải tiến nhỏ giữa các phiên bản. 4. Kiểm soát thay đổi Trong quá trình phát triển phần mềm có qui mô lớn không thể không có những thay đổi. Nếu những thay đổi này không được kiểm soát sẽ dẫn đến tình trạng thiếu nhất quán, hỗn độn trong toàn bộ hệ thống và dẫn đến sự thất bại của phần mềm. Chính vì vậy chúng ta cần có sự kiểm soát các thay đổi diễn ra trong quá trình xây dựng và phát triển hệ thống phần mềm. Phương thức được sử dụng để kiểm soát thay đổi là phối hợp cả các qui trình thủ tục, cả con người và các công cụ tự động để tạo ra một cơ chế kiểm soát sự thay đổi hiện quả. 4.1 Qui trình kiểm soát sự thay đổi 8
  10. * Sơ đồ qui trình kiểm soát sự thay đổi trong dự án phần mềm Nhận ra nhu cầu thay đổi Người dùng đệ trình yêu cầu thay đổi Người phát triển đánh giá Sinh ra các báo cáo về thay đổi Người có thẩm quyền quyết định kiểm soát thay đổi Xếp hạng yêu cầu, tạo thứ tự thay đổi Yêu cầu bị bác bỏ Phân đối tượng cấu hình cho cá nhân Thông báo cho người dùng Các khoản mục đối tượng cấu hình “Check out” Thực hiện thay đổi Rà soát thay đổi (kiểm toán) Các khoản mục đối tượng cấu hình “Check in” Thiết lập các đường mốc kiểm thử Tién hành các hoạt động đảm bảo chất lượng kiểm thử Xem lại các thay đổi sẽ được bao gồm trong lần phần phát mới Xây dựng lại phiên bản mới của phần mềm Rà soát sự thay đổi của các khoản mục cấu hình (kiểm toán) Bao gồm các thay đổi vào trong phiên bản mới Phân phối phiên bản mới Hình 3. Qui trình kiểm soát sự thay đổi trong dự án 9
  11. 4.2 Các hoạt động kiểm soát sự thay đổi Khi một yêu cầu thay đổi được đệ trình cần phải được xác định lại giá trị của yêu cầu thay đổi đó nhằm: - Sử dụng kỹ thuật thích hợp để thực hiện thay đổi đó. - Xác định các hiệu ứng phụ có thể ảnh hưởng lên tổng thể các đối tượng cấu hình khác và lên các chức năng hệ thống, lên chi phí dành cho dự án có thể diễn ra khi thực hiện sự thay đổi này. Kết quả đánh giá về sự thay đổi được báo cáo cho người có thẩm quyền kiểm soát thay đổi (CCA) – người có quyền cao nhất trong việc kiểm soát tình trạng và quyết định sự thay đổi đó có được thực hiện hay không. Khi một thay đổi được chấp thuận, một lệnh thay đổi kỹ thuật (ECO) được tạo ra. Lệnh này mô tả các đổi thay cần phải làm, các ràng buộc cần phải tuân thủ, các tiêu chuẩn rà soát và kiểm toán sẽ được thực hiện sau khi thực hiện thay đổi. Hình 4. Quá trình kiểm soát sự thay đổi trên các đối tượng Đối tượng cần thay đổi được “Check out” khỏi cơ sở dữ liệu dự án, được thực hiện sự thay đổi và các hoạt động bảo đảm chất lượng phần mềm cần được áp dụng. Sau đó, đối tượng này sẽ được “Check in” vào cơ sở dữ liệu và một cơ chế kiểm soát phiên bản được thực hiện. Quá trình “Check in” và “Check out” thực thi hai điều quan trong của kiểm soát thay đổi là kiểm soát truy cập và kiểm soát đồng bộ. Kiểm soát truy cập quản trị những gì mà người kỹ sư có thẩm quyền truy cập và sửa đổi đặc tả cấu hình 10
  12. đặc biệt. Kiểm soát đồng bộ giúp đảm bảo các thay đổi song song hoàn thành bởi những người khác nhau sẽ không bị viết đè lên nhau. Quá trình “Check out” một đặc tả cấu hình dựa trên yêu cầu thay đổi đã được chấp thuận và thứ tự thay đổi kỹ thuật cho phép người kỹ sư phần mềm có thể thực hiện. Chức năng kiểm soát truy câp sẽ đảm bảo rằng người kỹ sư phần mềm có thẩm quyền “Check out” các đối tượng đó và kiểm soát đồng bộ sẽ khoá đối tượng đó trong cơ sở dữ liệu dự án sao cho không thể cập nhật được dữ liệu này cho đến khi phiên bản “Check out” hiện thời được thay thế. Tuy nhiên, có thể có nhiều bản sao của cùng một đối tượng được “Check out” nhưng chỉ cỏ bản sao có thẩm quyền mới được cập nhật. Một bản sao của đối tượng đường mốc gọi là phiên bản trích ly được thay đổi bởi các kỹ sư. Sau khi được thay đổi và đảm bảo chất lượng phần mềm thì phiên bản thay đổi đó sẽ được “Check in” ngược trở lại cơ sở dữ liệu dự án và các đối tượng và đường mốc giới được xác lập liên quan đến đối tượng được thay đổi sẽ được mở khoá và thực hiện theo đối tượng đã được thực hiện thay đổi. Đường mốc được tạo ra khi đối tượng đó đã được rà soát kỹ thuật chính thức và được chấp thuận. Sau đó kiểm soát thay đổi mức dự án sẽ được thực thi. Trước hết, người phát triển phải được sự chấp thuận của người quản lý dự án (nếu dự án là cục bộ) hoặc được sự chấp thuận của người có thẩm quyền kiểm soát sự đổi thay nếu thay đổi ảnh hưởng đến các khoản mục khác trong cấu hình phần mềm. Quá trình kiểm soát thay đổi với nhiều thủ tục quá chặt chẽ có nguy cơ tạo ra sự cứng nhắc, quan liêu trong điều phối sự thay đổi. Nếu không tổ chức và kiểm tra tốt, sự kiểm soát thay đổi có thể dẫn đến việc cản trở tiến trình phát triển của cả dự án. Hầu hết các người phát triển phần mềm đều có cơ chế kiểm soát thay đổi, họ tạo ra một số tầng kiểm soát khác nhau trên những mức khác nhau trong dự án để việc kiểm soát thay đổi có thể dễ dàng được thực hiện và quản lý từ mức thấp đến mức cao của toàn thể dự án. Trong một số trường hợp, việc sinh ra nhiều thủ tục chính thức như các yêu cầu, các báo cáo thay đổi và thứ tự thay đổi có thể được bỏ qua. Tuy nhiên việc đánh giá từng thay đổi vẫn được tiến hành và tất cả các thay đổi vẫn được theo dõi và rà soát. Kiểm soát thay đổi chính thức được hình thành khi sản phẩm đã được phân phát cho 11
  13. khách hàng. Thẩm quyền kiểm soát thay đổi đóng một vai trò tích cực trong dự án phần mềm và phụ thuộc vào đặc tính của dự án phần mềm. Người có thẩm quyền cần có cái nhìn tổng thể, đánh giá được ảnh hưởng của thay đổi đối với các yếu tố bên ngoài các khoản mục cấu hình phần mềm như: - Thay đổi ảnh hưởng tới phần cứng như thế nào? - Thay đổi ảnh hưởng tới sự thực thi như thế nào? - Thay đổi ảnh hưởng tới sự nhìn nhận của khách hàng đối với sản phẩm như thế nào? - Thay đổi ảnh hưởng tới chất lượng và độ tin cậy của sản phẩm như thế nào? - ... 5. Kiểm toán cấu hình phần mềm Mục đích của việc kiểm soát phiên bản, kiểm soát sự thay đổi giúp người phát triển dự án duy trì được trật tự, tránh được tình trạnh hỗn độn trong toàn bộ hệ thống phần mềm. Tuy nhiên, ngay cả các cơ chế kiểm soát thành công nhất cũng chỉ theo dõi được sự thay đổi cho đến khi một đối tượng cấu hình kỹ thuật được sinh ra thay thế cho cấu hình đối tượng trước đó. Như vậy, làm thế nào để đảm bảo sợ thay đổi đó được thực thi? Để đảm bảo sự thay đổi đó được thực thi chúng ta cần có 2 hoạt động sau: - Rà soát kỹ thuật chính thức. - Kiểm toán cấu hình phần mềm. 5.1 Rà soát kỹ thuật chính thức Rà soát kỹ thuật chính thức tập trung vào sự đúng đắn về mặt kỹ thuật của đối tượng cấu hình đã được thực hiện sửa đổi. Người rà soát đánh giá sự phù hợp với các khoản mục và cấu hình khác có liên quan trong toàn bộ hệ thống phần mềm, tránh được việc bỏ sót và không kiểm soát được các hiệu ứng phụ có thể xảy ra khi đối tượng cấu hình này được thay đổi có thể gây nên. 5.2 Kiểm toán cấu hình phần mềm 12
  14. Kiểm toán cấu hình phần mềm là sự bổ sung cho rà soát kỹ thuật chính thức bằng cách đánh giá một đối tượng cấu hình trên các đặc tính mà thường không được xét đến trong quá trình rà soát. Kiểm toán cấu hình đòi hỏi và trả lời được các câu hỏi sau: - Thay đổi được đặc tả theo trật tự thay đổi kỹ thuật thông qua đã được thực hiện hay chưa? Những biến đổi phụ nào đã được thực hiện khi thực hiện sự thay đổi của cấu hình đối tượng này? - Rà soát kỹ thuật chính thức đã được tiến hành để đánh giá sự đúng đắn về mặt kỹ thuật hay chưa? - Các chuẩn kỹ nghệ phần mềm đã được thực sự tuân thủ trong quá trình thực hiện thay đổi chưa? - Thay đổi đó đã nổi bật lên trong các khoản mục phần mềm hay chưa? Có đặc tả ngày thực hiện và tác giả của sự thay đổi đó hay chưa? Các thuộc tính của đối tượng cấu hình đó đã phản ánh đầy đủ sự thay đổi đó chưa? - Các thủ tục quản lý cấu hình để giám sát, ghi lại và báo cáo về nó có được tuân thủ hay không? - Tất cả các khoản mục cấu hình phần mềm liên quan đã được thực sự cập nhật chưa? Trong một vài trường hợp các câu hỏi kiểm toán như là một phần của rà soát kỹ thuật phần mềm nhưng khi quản lý cấu hình phần mềm là một hoạt động chính thức thì kiểm toán quản lý cấu hình phần mềm lại được tách ra bở một nhóm bảo đảm chất lượng riêng. 6. Báo cáo hiện trạng Báo cáo tình trạng cấu hình (CSR: Configuration Status Report) còn gọi là kiếm toán tình trạng. Đây là một nhiệm vụ trong quản lý cấu hình phần mềm, việc thiết lập báo cáo hiện trạng giúp trả lời những câu hỏi sau: - Cái gì đã xảy ra? - Ai làm? Ai đã thực hiện? 13
  15. - Việc thay đổi đó xảy ra khi nào? - Thay đổi đó có còn ảnh hưởng nào khác nữa không? Thông tin báo cáo tình trạng cấu hình gắn chặt với các nhiệm vụ trong phần kiểm soát thay đổi. Mỗi khi một khoản mục cấu hình phần mềm được ấn định mới hoặc được cập nhật các chức thư thay đổi thì một nội dung (Entry) sẽ được tạo ra. Mỗi khi một khoản mục cấu hình phần mềm được chấp thuận bởi người có thẩm quyền thay đổi cấu hình (có một mệnh lệnh thay đổi kỹ thuật được tạo ra) thì nội dung cũng được tạo ra. Mỗi khi một kiểm toán cấu hình được tiến hành thì các kết quả của nó được báo cáo như là một phần của nhiệm vụ báo cáo trạng thái cấu hình. Đầu ra của báo cáo tình trạng cấu hình có thể được đặt trên một cơ sở dữ liệu trực tuyến sao cho những người phát triển phần mềm hay bảo trì có thể truy cập các thông tin đã được thay đổi. Báo cáo tình trạng cấu hình phần mềm đóng một vai trò cốt lõi trong thắng lợi của một dự án phát triển phần mềm lớn. Báo cáo tình trạng cấu hình giúp ta loại trờ vấn đề bất cập liên quan nhiều người bằng cách cải thiện giao tiếp giữa các thành viên. Nếu không có báo cáo tình trạng cấu hình có thể dẫn đến sự lãng phí về mặt thời gian và nhân lực khi cùng một sự thay đổi đối tượng cấu hình lại được thực hiện đi thực hiện lại nhiều lần bởi nhiều nhóm khác nhau. 7. Một số công cụ tự động hỗ trợ quản lý cấu hình và quản lý thay đổi Mỗi một khâu trong qui trình quản lý cấu hình và quản lý thay đổi phần mềm đều có nhiều lớp công cụ khác nhau. Ở đây xin trình bày một số công cụ hỗ trợ chính. 7.1 Công cụ hỗ trợ cho sự cộng tác (Collaborative Work Tools) Công nghệ Media Space cho phép nhiều người tham gia vào cuộc thảo luận nhìn thấy người đối diện của mình thông qua bộ hiển thị là bản mạch thuỷ tinh trong suốt có bộ nhớ điện tử trong đó (Clear Board). Board có thể hiện thị hình ảnh của máy tính, văn bản và đồ hoạ trung thực, sống động của những người tham gia cuộc họp. Clear Board cho phép con người theo dõi được cả công việc của mình và công việc của người đang cùng làm việc với mình, làm tiết kiệm thời gian. Công cụ này được phát triển tại Xerox PARC. 14
  16. Bảng 1. Một số công cụ hỗ trợ cho sự cộng tác: STT Tên công cụ Nhà cung cấp Chức năng 1 Cruiserd Bellcore Morristown, NJ Chương trình vẽ đa người NeXT Computer Moutain dùng 2 Greyboard View, CA Dept. of Computer Science Bộ ứng dụng thời gian 3 Groupkit University of Calgary, thực chạy trên nền UNIX Alberta, Canada 4 Notes Lotus Deverlopment Corp MA Email chia sẻ dữ liệu Oracle Corp, Email phát triển ứng dụng Oracle Mail, Redwood City CA và giao diện cho chương 5 Alert, Toolkit trình ứng dụng trên mạng anf Glue LAN Farallon Computing, Inc Chia sẻ phần mềm mềm TM 6 Timbuktu Bekelye, CA một người dùng cho nhiều người dùng ACMSIGCHI Chương trình vẽ nhiều Video roceedings’91,pp người dùng 7 Whiteboard 315-322 ACMSIGCHI 8 VideoDraw roceedings’90,pp 313-320 7.2 Công cụ hỗ trợ về tài liệu (Documentation Tools) Là các công cụ cung cấp tiến trình xử lý từ như WordPerfect nhanh chóng bị thay thế bằng các phần mềm thông minh hơn là các công cụ phát triển tài liệu có khả năng được sử dụng lâu dài. Một trong những khó khăn của tiến trình xử lý từ văn bản là bằng cách nào đó tạo được bản sao hoặc tham khảo chéo các chủ đề khác nhau nhưng có quan hệ qua lại với nhau. Phần mền Hypertext đã loại bỏ được khó khăn này thông qua việc cho phép thiết lập quan hệ giữa các mục văn bản. Phần mềm Hypermedia mở rộng của Hypertext cung cấp audio, video, ảnh đồ hoạ, văn bản và cả dữ liệu. Trong Hypermedia các công nghệ đa chức năng này tác động qua lại với nhau và cùng thực thi trên một môi trường. Hơn nữa, do các công cụ không giới hạn số các kết nối tới một mục và do sử dụng kỹ thuật luôn kết nối máy tính liên tục nên các ứng dụng về tài 15
  17. liệu được giữ ở trạng thái trực tuyến và có khả năng cung cấp các hoạt động qua lại đối với tất cả những thành viên tham gia phát triển. Khả năng cung cấp các hoạt động qua lại này bao gồm một đối tượng quản lý HyperLibrary để quản lý những thay đổi trong nội dung thư viện. Bảng 2. Một số công cụ duy trì tài liệu STT Tên công cụ Nhà cung cấp Chức năng Folio Provo, UT Tiện ích đi kèm WordPerfect hỗ trợ đa 1 Folio Views phương tiện và một số tình năng đặc biệt khác Apple Computer Cho phép kết hợp văn bản 2 HipertextMT Cupertino, CA với đồ hoạ Microsoft Inc Xử lý văn bản, hình ảnh 3 Microsoft Word Belleview, WA và kiểm tra ngữ pháp Word Perfect and Word Word Perfect Corp, Xử lý văn bản và kiểm tra 4 Perfect Mac with Orem, UT ngữ pháp Gramatik Ludeen and Cho phép kết hợp văn bản 5 Word and Beyond Associate Alameda, với đồ hoạ CA 7.3 Công cụ đối chiếu thiết kế phần mềm (Tools for Reverse Engineering of Software) Các công cụ này cho phép đối chiếu thiết kế nhanh chóng để người phát triển phần mềm có thể kiểm soát được hệ thống. Một vài sản phẩm CASE cung cấp công cụ đối chiếu thông qua sự phân tích mã để quyết định cấu trúc dữ liệu là cơ sở của tiến trình xây dựng tạo mã cho ứng dụng. Các công cụ này cho phép phân tích, chỉ ra những mâu thuẫn trong đặc tả các đối tượng, những lỗi tham khảo chéo của những đoạn mã rối… Bảng 3. Một số công cụ dùng cho thiết kế STT Tên công cụ Nhà cung cấp Chức năng ADW/Maintenance Knowledge Ware, Inc Tạo sơ đồ quan hệ và 1 Workstation Atlanta, GA biểu đồ luồng dữ liệu 2 Bachman Series Bachman Information Tạo cấu trúc dữ liệu. 16
  18. System, Inc, Burlington, MA Intersolv, Inc Tạo cấu trúc chương 3 Design Recovery trình Carde Technologies, Inc, Tạo các đối tượng hình 4 Ensemble providence, RI học, biểu đồ. Advance Software Dùng cho ngôn ngữ C: 5 Hindsight Automation, Inc, Santa tạo tài liệu, biểu đồ cấu Clara, CA trúc, phân tích đầy đủ. Texas Instument, Inc with Tạo sơ đồ quan hệ thực 6 RE for IE Price Waterhouse thể, biểu đồ luồng dữ liệu. Procase Corp. Santa Clara, Tạo cấu trúc dữ liệu 7 Smartsystem CA 8 Via/Reaissance Viasoft, Inc, Phoenix, AZ Microsoft Inc Belleview, Tạo sơ đồ quan hệ thực 9 Microsoft Visio WA thể, biểu đồ luồng dữ liệu. 7.4 Công cụ quản lý cấu hình (Tools for Configuration Management) Những công cụ quản lý cấu hình thương được gọi là thư viện phần mềm hay thư viện mã được hình thành vào những năm 70. Các công cụ này cung cấp những mô hình mới hơn, quản lý các biến đổi dễ dàng hơn nhờ các chức năng giải quyết các vấn đề phức tạp như biên dịch điều kiện. Bảng 4. Một số công cụ dùng cho quản lý cấu hình phần mềm STT Tên công cụ Nhà cung cấp Chức năng IBM Armonk, NY Cung cấp thư viện phần mềm cho 1 Copylib các máy tính mainframe IBM Data Administration, Quản lý dữ liệu, dùng để xem các 2 Data Expeditor Inc định nghĩa file của các cung cấp như Copylib, Librarain, Panvalet. Pansophic System, Inc Cung cấp thư viện phần mềm cho 3 Librarain các máy tính mainframe IBM Liste, IL Pansophic Systems, Inc Cung cấp thư viện phần mềm cho 4 Panvalet các máy tính mainframe IBM Liste, IL 5 RUP (Rational Rationnal Quản lý toàn bộ các cấu hình liên Unified quan đến việc phát triển phần 17
  19. Process) mềm…. 8. Vài nét về USDP (Unified Software Development Process) 8.1 Giới thiệu chung UML là ngôn ngữ mô hình hợp nhất giúp xác định toàn bộ hệ thống phần mềm dưới dạng hình thức, nghĩa là nó không định nghĩa qui trình phân tích, thiết kế và cài đặt hệ thống. Những người phát triển UML tạo ra một đặc tả của một qui trình phát triển phần mềm nhằm giải thích cho cách suy nghĩ của họ về việc xây dựng hệ thống phần mềm. Hình 5. Mô hình hợp nhất (UP) Qui trình phát triển phần mềm theo hướng này gọi là Qui trình phát triển phần mềm hợp nhất (USDP - Unified Software Development Process) hay Qui trình hợp nhất Rational (RUP - Rational Unified Process) hay đơn giản hơn còn gọi là Qui trình hợp nhất (UP - Unified Process). Qui trình hợp nhất bao gồm con người, dự án, sản phẩm, qui trình và công cụ. Con người là đối tượng tham gia, là người phát triển dự án nhằm tạo ra sản phẩm phần mềm theo một qui trình và dùng công cụ tự động để hỗ trợ. Qui trình hợp nhất là một qui trình tiếp cận theo tình huống sử dụng (Use-case-driven). Nghĩa là yêu cầu của người sử dụng được mô tả trong các use-case, là một chuỗi các hành động được thực hiện bởi hệ thống nhằm cung cấp một điều gì đó cho người dùng. Các use-case này được người phát triển sử dụng như nền tảng của chuỗi công việc để tạo ra mô hình thiết kế và mô hình cài đặt. 8.2 Lịch sử phát triển 18
  20. Hình 6.Lịch sử phát triển của RUP 8.3 Kiến trúc tổng quát của RUP Hình 7.Kiến trúc tổng quát của RUP RUP được tổ chức theo 2 trục: + Trục hoành: tổ chức theo thời gian phát triển dự án, thể hiện khía cạnh động của qui trình phát triển. Bao gồm: - Chu kỳ (Cycles) - Các pha (Phases) 19

CÓ THỂ BẠN MUỐN DOWNLOAD

Đồng bộ tài khoản