Deployment triển khai: thực hiện cài đặt chương trình, thay đổi yêu cầu củakhách hàng, nâng cấp chương trình... Khó khănthậm chí còn tăng nên gấp bội nếu kỹ sư bảo
Trang 1HỌC VIỆN KỸ THUẬT MẬT MÃ
BÀI TẬP MÔN CÔNG NGHỆ PHẦN MỀM
ĐỀ TÀI 12: TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM
Sinh viên thực hiện: PhaLiNha
Trang 2MỤC LỤC
I BẢO TRÌ PHẦN MỀM 4
1 Tổng quan 4
1.1 Khái niệm 4
1.2 Khó khăn 5
2 Phân loại 7
2.1 Bảo trì tu sửa 8
2.2 Bảo trì thích nghi 9
2.3 Bảo trì cải tiến 9
2.4 Bảo trì phòng ngừa 9
3 Ý nghĩa 9
4 Mô hình bảo trì phần mềm 10
4.1 Mô hình Quick-Fix 10
4.2 Mô hình Iterative Enhancement 11
4.3 Mô hình Full-reuse 12
5 Công việc bảo trì phần mềm 13
5.1 Khả năng bảo trì 13
5.2 Các công việc bảo trì 14
5.3 Định giá bảo trì 16
II QUY TRÌNH BẢO TRÌ PHẦN MỀM 19
1 Quy trình bảo trì tổng quát 19
1.1 Chuẩn bảo trì phần mềm IEEE 1291 20
1.2 Chuẩn ISO/IEC 14764 25
2 Quy trình bảo trì cho một website 26
2.1 Nguyên nhân cần phải bảo trì website 26
2.2 Quy trình bảo trì chung cho một website 27
III KẾT LUẬN 29
IV.TÀI LIỆU THAM KHẢO 29
Trang 3Danh mục hình vẽ
Hình 1: Chu kỳ sống của phần mềm Hình 2: Phân loại bảo trì
Hình 3: Quick-fix Hình 4: Iterative Enhancement model Hình 5: Full-reuse
Hình 6: Chi phí phát triển phần mềm Hình 7: Mô hình bảo trì phần mềm Hình 8: Các hoạt động trong quy trình bảo trì phần mềm Hình 9: ISO/IEC 14764
Trang 4I BẢO TRÌ PHẦN MỀM
1 Tổng quan
1.1 Khái niệm
Phần mềm là tập các câu lệnh hoặc chỉ thị được viết bằng một hoặc nhiều ngônngữ lập trình theo một trật tự nhất định Dữ liệu hay các tài liệu liên quan được xâydựng nhằm thực hiện một số nhiệm vụ hay chức năng Để có thể xây dựng nên mộtphần mềm hoàn thiện phục vụ yêu cầu của người dùng cần trải qua một quy trìnhphát triển phần mềm gồm nhiều giai đoạn khác nhau Quy trình phát triển phần mềmlà một cấu trúc bao gồm tập hợp các thao tác và các kết quả tương quan sử dụngtrong việc phát triển để sản xuất ra một sản phẩm phần mềm Để có một quy chuẩncho quy trình phát triển phần mềm, tổ chức ISO/IEC đã đưa ra chuẩn ISO/IEC
12207 Mục đích là trở thành một tiêu chuẩn định nghĩa tất cả các công việc cầnthực hiện để xây dựng và bảo trì sản phẩm phần mềm Theo chuẩn này, có 4 thao tác
cơ bản là nền tảng cho quy trình phát triển phần mềm
Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện hoạt động củanó phải được định nghĩa
Sự phát triển của phần mềm: Để phần mềm đạt được đặc tả thì cần có quytrình này
Đánh giá phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nólàm những gì mà khách hàng muốn
Sự tiến hóa của phần mềm: Phần mềm phải được tiến hóa để thỏa mãn sựthay đổi các yêu cầu của khách hàng
Một quy trình phát triển phần mềm (chu kỳ sống của phần mềm) gồm các giaiđoạn cơ bản sau:
Requirements (phân tích yêu cầu): Thu thập yêu cầu của khách hàng về phầnmềm, phân tích và đặc tả chi tiết về những yêu cầu đó
Design (thiết kế): chuyển tài liệu đặc tả yêu cầu ở bước trên thành tài liệu môtả thiết kế
Coding (lập trình): thực hiện mã hóa tài liệu thiết kế thành mã chương trình
Testing (kiểm thử): chạy thử chương trình, phát hiện lỗi hay khả chuyển phầnmềm để phù hợp với các phần mềm khác
Deployment (triển khai): thực hiện cài đặt chương trình, thay đổi yêu cầu củakhách hàng, nâng cấp chương trình
Trang 5Hình 1: Chu kỳ sống của phần mềm
Theo quy trình trên thì việc thực hiện bảo trì phần mềm sẽ được thực hiện ở giaiđoạn triển khai phần mềm và là phần cuối cùng trong một chu kỳ sống của phầnmềm Bảo trì phần mềm (software maintenance) bao gồm điều chỉnh các lỗi màchưa được phát hiện trong các giai đoạn trước của chu kỳ sống của một phần mềm,nâng cấp tính năng sử dụng và an toàn vận hành của phần mềm Việc bảo trì phầnmềm có thể chiếm đến 65%-75% công sức trong chu kỳ sống của một phần mềm.Nhiệm vụ của giai đoạn bảo trì phần mềm nhằm giữ cho phần mềm được cập nhậtkhi môi trường vận hành thay đổi và yêu cầu của khách hàng thay đổi Theo chuẩnIEEE(1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần mềmsau khi đã bàn giao để chỉnh lại các lỗi phát sinh, cải thiện hiệu năng của phần mềmhoặc các thuộc tính khác, hoặc làm cho phần mềm thích ứng trong một môi trườngđã bị thay đổi
1.2 Khó khăn
Việc bảo trì phần mềm sẽ chịu ảnh hưởng trực tiếp từ nhiều yếu tố như: kíchthước của hệ thống, tuổi của hệ thống, đầu ra và cấu trúc của dữ liệu, ngôn ngữ lậptrình, hay độ dài của mã nguồn Hệ thống phần mềm và thông tin đi kèm luôn cóbiến động lớn theo thời gian, gây khó khăn trong việc đọc hiểu và bảo trì, do khôngcó sự kết nối chặt chẽ giữa các thành phần phần mềm và trung tâm dữ liệu của hệthống Chìa khóa của việc bảo trì một hệ thống phức tạp là phải hiểu chúng, phải
Trang 6hiểu sâu về các thành phần chức năng, phi chức năng, và các tương tác giữa chúng.Đặc biệt, khó khăn nhất nằm trong phần mã nguồn, nhiều nghiên cứu đã chỉ ra rằngchi phí dành cho việc đọc hiểu mã nguồn chiếm một phần rất lớn trong toàn bộ chiphí bảo trì phần mềm Theo quy mô của hệ thống, lượng mã nguồn và các mối quanhệ giữa các thành phần mã nguồn cũng ngày một tăng nhanh, cả về số lượng và độphức tạp, gây ra rất nhiều khó khăn cho người bảo trì trong việc đọc hiểu và xácđịnh đoạn mã cần được tập trung bảo trì.
Các liên kết truy vết giúp cho các kĩ sư phần mềm hiểu được mối quan hệ và sựphụ thuộc giữa các thành phần phần mềm từ đó giúp đỡ cho quá trình đọc hiểu mãnguồn Tuy nhiên, ngay trong các tổ chức và dự án với quy trình phát triển phầnmềm thuần thục, các thành phần phần mềm được tạo ra trong các bước của quy trìnhnày cuối cùng cũng bị mất liên kết với các thành phần khác Các nhân tố chủ yếudẫn đến việc mất liên kết giữa các thành phần phần mềm bao gồm:
Các thành phần phần mềm khác nhau được viết bằng các ngôn ngữ khác nhau(ngôn ngữ tự nhiên và ngôn ngữ lập trình)
Các thành phần phần mềm mô tả hệ thống phần mềm ở các cấp độ trừu tượngkhác nhau (cấp độ thiết kế và cài đặt)
Các quy trình làm thay đổi một thành phần giả tưởng(artifact) không dẫn đếncác sửa đổi liên kết đang tồn tại giữa nó với các thành phần giảtưởng(artifact) khác (Ví dụ: khi sửa mã thì không có đưa ra cảnh báo choviệc sửa tài liệu sử dụng của mã đó)
Thiếu các công cụ hỗ trợ việc tạo và duy trì các liên kết truy vết này
Các nghiên cứu tạo liên kết truy vết giữa mã nguồn và tài liệu cho đến nay chủyếu tập chung vào việc kết nối tài liệu và mã nguồn dựa trên những liên kết một-một Hạn chế lớn nhất của phương pháp này là đã bỏ qua các thông tin ngữ nghĩa,có cấu trúc có thể tìm thấy trong các tài liệu và mã nguồn, dẫn đến sự thiếu chínhxác và khả năng ứng dụng trong thực tế không được cao
Một thách thức khác đó là việc xác định các nguy cơ bảo mật Đối với các ứngdụng được đặt vào các môi trường thay đổi sẽ có độ rủi ro bảo mật cao, việc xácđịnh những lỗ hổng bảo mật này trong các hệ thống phần mềm tồn tại trở thành mộttrong những công việc quan trọng trong giai đoạn bảo trì phần mềm Trong khi mãnguồn ngày càng tăng nhanh thì vấn đề này lại càng trở lên ngày càng khó khăn bởiđể phát hiện được các nguy cơ bảo mật thì người bảo trì phải thực sự hiểu được hệthống của mình
Một thách thức khác gặp phải trong quá trình bảo trì hệ thống là một kỹ sư phầnmềm,theo thời gian cũng không còn nắm rõ được các thông tin về kiến trúc, về mã
Trang 7nguồn, hay rộng hơn là các giả tưởng(artifact) do chính họ tạo ra nữa Khó khănthậm chí còn tăng nên gấp bội nếu kỹ sư bảo trì không trực tiếp tham gia trong quátrình phát triển phần mềm Tương tự như vậy, nếu không được hỗ trợ, người kỹ sưsẽ gặp khó khăn không nhỏ khi muốn tái sử dụng các artifact của chính mình, chưanói đến tái sử dụng artifact sẵn có của người khác.
Việc tìm kiếm, phân tích và tìm hiểu mã nguồn đóng vai trò rất quan trọng Tuynhiên, ngay trong những IDE (Integrated Development Environment-môi trườngphát triển tích hợp) phát triển phần mềm mạnh nhất như Eclipse, việc hỗ trợ tìmkiếm cũng không mạnh mẽ khi chỉ đơn thuần tìm kiếm văn bản riêng lẻ, thôngthường theo tên các method, class, …mà không hỗ trợ tìm kiếm kết hợp giữa cácthành phần này Người lập trình rất hay gặp phải những tình huống tìm kiếm như:tìm kiếm các phương thức nhận một kiểu nào đó làm đối số đầu vào hay tìm kiếmcác phương thức trả về một kiểu dữ liệu nào đó Hiện nay chưa có một IDE nào thỏamãn các yêu cầu tìm kiếm này đơn giản là bởi vì chúng không khai thác tính ngữnghĩa giữa các thành phần của mã nguồn để thực hiện tìm kiếm Ngoài ra việc bảotrì phần mềm sẽ gặp không ít khó khăn khi môi trường vận hành không phù hợp, cósự tích hợp chồng chéo, không tương thích của các phần mềm Thiếu kinh nghiệmkiểm chuẩn, xác định phương pháp, chiến lược cho bảo trì Yêu cầu của khách hàngquá nhiều và luôn thay đổi
Để khắc phục những khó khăn trên, tăng hiệu quả cho quá trình bảo trì phầnmềm chúng ta nên sử dụng một số biện pháp sau:
Lưu lại đầy đủ, chính xác thông tin về phần mềm
Chuẩn hóa các thao tác kiểm chuẩn, bảo trì
Sử dụng các công cụ hỗ trợ phát triển và bảo trì phần mềm
Lựa chọn môi trường vận hành thích hợp với từng phần mềm
2 Phân loại
Theo chuẩn IEEE thì bảo trì phần mềm được phân thành 4 loại:
Bảo trì tu sửa (Corrective Maintenance)
Bảo trì thích nghi (Adaptive Maintenance)
Bảo trì cải tiến (Perfective Maintenance)
Bảo trì phòng ngừa (Preventive Maintenance)
Trang 8Hình 2: Phân loại bảo trì
2.1 Bảo trì tu sửa
Bảo trì tu sửa (Corrective Maintenance) là bảo trì được thực hiện nhằm sửa cáclỗi hay khuyết điểm phát sinh được tìm thấy Lỗi hay khuyết điểm thường phát sinhdo:
Lỗi thiết kế: xuất hiện khi những sự thay đổi, cập nhật làm cho phần mềmhoạt động không còn chính xác, đầy đủ, thậm chí là truyền đạt sai hay nhữngyêu cầu thay đổi bị hiểu sai
Lỗi logic: xuất hiện do việc thực hiện giai đoạn kiểm tra, đưa ra kết luận sai,thực hiện không đúng theo thiết kế chi tiết kỹ thuật hoặc dữ liệu không đượckiểm tra đầy đủ
Lỗi coding: do người lập trình thực hiện không đúng các quy tắc chi tiết thiếtkế hoặc không tuân thủ theo các quy tắc logic mã nguồn
Ngoài ra còn xuất hiện do việc xử lý dữ liệu hay vận hành hệ thống gặp lỗi.Bảo trì tu sửa thường sử dụng kỹ thuật dịch ngược (Reverse Enginnering) dòtheo thiết kế để tìm lỗi
Trang 92.2 Bảo trì thích nghi
Bảo trì thích nghi (Adaptive Maintenance) là bảo trì được thực hiện nhằm chỉnhsửa phần mềm, làm cho phần mềm hoạt động được bình thường khi có sự thay đổicủa môi trường Môi trường ở đây được hiểu là tất cả các ảnh hưởng, hành động bênngoài tác động làm cho phần mềm không còn hoạt động chính xác nữa Đó có thể làsự thay đổi về chính sách kinh doanh, quy tắc hoạt động của công ty, mô hình làmviệc hay sự thay đổi của các thiết bị phần cứng, hệ điều hành, hoặc các thiết bị đikèm…
2.3 Bảo trì cải tiến
Khi phần mềm được hoàn thiện và đưa vào sử dụng thành công, người dùng sẽcàng quan tâm đến nó Việc này sẽ dẫn đến việc người dùng muốn thử các chứcnăng vượt ra ngoài phạm vi của phần mềm, do đó sẽ dẫn tới việc người dùng sẽ đặt
ra các yêu cầu mới Việc bảo trì cải tiến (Perfective Maintenance) là bảo trì đượcthực hiện nhằm thay đổi phần mềm theo những yêu cầu ngày càng hoàn thiện hơn,đầy đủ hơn, hợp lý hơn Đây là hình thái bảo trì phổ biến nhất trong thực tế Việctiến hành bảo trì được đặt ra khi khách hàng muốn nâng cao hiệu suất, cải tiếnphương thức truy nhập, mở rộng thêm chức năng cho hệ thống, cải tiến quản lý làmcải tiến tư liệu vận hành và trình tự công việc, hay có thể do thay đổi người dùngdẫn đến thay đổi các thao tác thực hiện
2.4 Bảo trì phòng ngừa
Bảo trì phòng ngừa (Preventive Maintenance) sẽ quan tâm tới các hoạt độngnhằm tăng cường khả năng có thể bảo trì của hệ thống, như cập nhật dữ liệu, ghichú, cải thiện cấu trúc của hệ thống Việc bảo trì này là sự tu sửa phần mềm có tínhđến tương lai của phần mềm đó sẽ được mở rộng hay thay đổi như thế nào nhằmgiảm bớt độ phức tạp của hệ thống và làm cho các lần bảo trì sau trở dễ dàng hơn
3 Ý nghĩa
Bảo trì là giai đoạn cuối cùng trong một chu kỳ sống của phần mềm, nhằm nângcấp tính năng của phần mềm và làm cho phần mềm hoạt động ổn định, hiệu quảhơn Bảo trì phần mềm để chắc chắn rằng phần mềm tạo ra thỏa mãn được đầy đủ,chính xác các yêu cầu của khách hàng Bảo trì cần phải thực hiện để:
Chỉnh sửa các lỗi
Nâng cao thiết kế
Có thể cài đặt nâng cao
Giao tiếp được với các hệ thống khác
Trang 10 Thích ứng được chương trình với các phần cứng, phần mềm, các phương tiệntruyền thống khác.
Giúp hệ thống dễ sử dụng lại trong các lần tiếp theo
Bảo trì sẽ được thực hiện theo định kỳ, thực hiện khi có sự cố xảy ra hay khi yêucầu của khách hàng thay đổi Với một hệ thống mạng Server việc bảo trì là rất quantrọng, cần phải được thực hiện theo định kỳ để đảm bảo hệ thống hoạt động đượcliên tục, ổn định Bởi một hệ thống Server thì yêu cầu hoạt động liên tục là thực sựquan trọng, để đáp ứng được các yêu cầu của các client.Với hệ thống mạng nội bộ(ví dụ như trong một phòng ban của công ty) thì việc bảo trì có thể chỉ cần khi phầnmềm đó gặp sự cố Bởi mức độ yêu cầu phần mềm cần hoạt động liên tục khôngcao, tầm ảnh hưởng của bảo trì là không lớn Trong hệ thống ngân hàng (ghi chi phí,thanh toán tiền) thì việc bảo trì cũng cần được thực hiện định kỳ, bởi yêu cầu vềchức năng của phần mềm trong lĩnh vực này rất cao, luôn đòi hỏi không được xảy rasai sót Việc bảo trì cần đảm bảo cho hệ thống được vận hành ổn định, chính xác.Trong một hệ thống mạng nhiều ứng dụng như các phần mềm trên mobile thì yêucầu của bảo trì là thường xuyên, nhưng không cao Bởi trong những hệ thống này thìmôi trường hoạt động luôn thay đổi, yêu cầu của khách hàng cũng thay đổi theo sựphát triển của khoa học công nghệ Việc bảo trì trong hệ thống này chủ yếu do sựphát triển và yêu cầu ngày một cao của khách hàng
4 Mô hình bảo trì phần mềm
4.1 Mô hình Quick-Fix
Hình 3: Quick-fix
Trang 11Mô hình Quick-fix đại diện cho một sự trừu tượng của cách tiếp cận điển hình đểbảo trì phần mềm Trong mô hình Quick-fix, bạn sẽ sử dụng những thứ hệ thốnghiện có, thường chỉ là mã nguồn và thực hiện những thay đổi cần thiết đến mãnguồn và các tài liệu kèm theo, sau đó biên dịch lại các hệ thống như là một phiênbản mới Điều này có thể đơn giản như một sự thay đổi một số thành phần bên trongnhư sửa một lỗi liên quan đến một thành phần hoặc sự thay đổi cấu trúc hoặc thậmchí một số chức năng cao hơn Hình 3 cho thấy sự thay đổi của mã nguồn của hệthống cũ sang mã nguồn của phiên bản mới Nó được giả định rằng – không phải lúcnào cũng đúng – tài liệu kèm theo hướng dẫn cũng được cập nhật Bạn có thể hiểu
mô hình này theo hướng tái sử dụng, vì việc tạo ra một hệ thống mới bằng cách táisử dụng hệ thống cũ hay chỉ đơn giản là sửa đổi hệ thống cũ
Ưu điểm:
Nhanh.
Có thể hữu ích cho dự án nhỏ
Nhược điểm:
Nhỏ hay không có tài liệu Vai trò của tài liệu bị giảm sút
Do can thiệp trực tiếp vào code của chương trình nguồn nên quá trình bảo trìcó thể sẽ phá vỡ thiết kế ban đầu của phần mềm
4.2 Mô hình Iterative Enhancement
Hình 4: Iterative Enhancement model
Trang 12Dựa trên nhận định rằng một hệ thống khi xây dựng rất khó có thể đã đáp ứng được hết yêu cầu của người sử dụng, phương pháp interative- enhance tiến hành xây dựng hệ thống hoàn chỉnh dựa trên cơ sở phân tích bước đầu về yêu cầucủa hệ thống, tiến hành phân tích sâu hơn yêu cầu đặt ra đối với phần mềm dựa trên phản hồi của người sử dụng để xây dựng hệ thống mới
Ưu điểm:
Tương đối đơn giản
So với quick-fix là các tài liệu của hệ thống được cập nhật thường xuyên với mọi sự thay đổi của hệ thống
Nhược điểm:
Những quyết định, yêu cầu không rõ ràng
4.3 Mô hình Full-reuse
Hình 5: Full-reuse
Mục đích của tái sử dụng lại là nhằm tăng năng suất, chất lượng và tạo điều kiệnthuận lợi cho việc chuyển đổi mã, giảm bớt thời gian chi phí để bảo trì Có thể hiểuđịnh nghĩa của việc tái sử dụng phần mềm như sau: đó là việc sử dụng lại các kinh
Trang 13nghiệm đã có từ chính hệ thống đó hay các hệ thống tương tự nhằm giảm bớt nỗ lựcđể phát triển hay bảo trì hệ thống
Ứng dụng tư tưởng tái sử dụng, phương pháp full-reuse xây dựng hệ thống mớitrên cơ sở tái sử dụng những yếu tố phù hợp trong từng giai đoạn khi xây dựng hệthống cũ Do đó, phương pháp này thích hợp cho việc xây dựng những hệ thống cóvòng đời ngắn Tăng khả năng tái sử dụng của các thành phần hệ thống Đặc biệt,khi kết hợp full-reuse và interative enhancement có thể tăng đáng kể hiệu quả kinhtế của quá trình bảo trì phần mềm
Ưu điểm:
Có thể dùng các thành phần từ các dự án khác
Mã nguồn được chia thành các modun nhỏ
Nhược điểm:
Chi phí trong thiết kế để tái sử dụng cao
5 Công việc bảo trì phần mềm
5.1 Khả năng bảo trì
Khả năng bảo trì của phần mềm có thể coi như các khả năng hiểu, hiệu chỉnhhoặc có thể thêm vào khả năng phát triển phần mềm Khả năng bảo trì là chìa khóađể dẫn đến các phương pháp thiết kế xây dựng phần mềm
5.1.1 Yếu tố kiểm soát
Khả năng bảo trì gồm nhiều yếu tố như: sự thiếu cẩn trọng trong việc thiết kế,viết chương trình nguồn, kiểm tra, cấu hình yếu kém có ảnh hưởng tiêu cực đến việcbảo trì Thêm vào đó các yếu tố khác liên quan đến phương pháp phát triến phầnmềm như:
Chất lượng hiệu quả của đội ngũ phần mềm
Cấu trúc của hệ thống dễ hiểu
Dễ dàng kiểm soát hệ thống
Dùng các ngôn ngữ lập trình chuẩn
Dùng các hệ điều hành chuẩn
Dùng các cấu trúc chuẩn tài liệu
Dùng được các tài liệu kiểm tra
Phương tiện gỡ rối đi kèm
Trang 14 Dùng được các máy tính tốt để thực hiện việc bảo trì
Các yếu tố ở trên đã phản ánh những đặc điểm về phần cứng cũng như chươngtrình nguồn được dùng trong việc phát triển phần mềm và còn chỉ ra được sự cầnthiết để có được chương trình nguồn chuẩn Nếu coi phần mềm như một hệ thốngcác thành phần sẽ phải chịu những thay đổi không thể tránh được thì cơ hội tạo ranhững phần mềm có khả năng bảo trì sẽ thực sự tăng lên
5.1.2 Đánh giá định lượng
Khả năng bảo trì cũng như chất lượng hay độ tin cậy là hết sức khó xác định.Tuy nhiên chúng ta có thể đánh giá khả năng bảo trì gián tiếp bằng việc xem xét cácthuộc tính của các công việc bảo trì có thể đánh giá được như:
Thời gian nhận biết vấn đề
Thời gian trễ do các công việc hành chính
Thời gian lựa chọn công cụ bảo trì
Thời gian phân tích vấn đề
Thời gian xác định sự thay đổi
Thời gian hiệu chỉnh (hay sửa đổi) thực sự
Thời gian chạy thử cục bộ
Thời gian chạy thử tổng thể
Thời gian tổng kết bảo trì
Tổng thời gian của công việc bảo trì
Mỗi đánh giá trên thực tế là các dữ liệu có thể cung cấp cho người quản lý vềhiệu quả của công việc
5.2 Các công việc bảo trì
5.2.1 Cơ cấu bảo trì
Tức là những yêu cầu bảo trì được chuyển cho người kiểm soát công việc bảo trìvà từ đây chuyển tiếp yêu cầu tới người quản lý hệ thống để đánh giá, người quản lýhệ thống là thành viên của nhóm nhân viên kỹ thuật Những nhân viên này có tráchnhiệm về một phần nhỏ của chương trình sản phẩm Khi một yêu cầu được đánh giá,người được ủy quyền quản lý việc thay đổi phải quyết định hành động nào đượcthực hiện tiếp Cơ cấu được miêu tả ở trên phục vụ cho việc thiết lập phạm vi tráchnhiệm đối với công việc bảo trì Người kiểm soát và người ủy quyền quản lý việcthay đổi có thể là một người hay một nhóm quản lý và chuyên gia kỹ thuật cao cấp
Trang 15Yêu cầu bảo trì
Người quản lý quá trình bảo trì (maintenance manager)Người quản lý hệ thống
5.2.2 Báo cáo
Tất cả các yêu cầu về việc bảo trì phần mềm cần được trình bày theo mộttiêu chuẩn Người phát triển phần mềm thường cung cấp một đơn yêu cầu bảo trìcòn được gọi là báo cáo các lỗi phần mềm Báo cáo này được người sử dụng điềnvào khi yêu cầu công việc bảo trì Nếu xuất hiện một lỗi, bản mô tả đầy đủ tìnhhuống dẫn đến lỗi bao gồm dữ liệu, đoạn chương trình và các yêu cầu khác phảiđược điền đầy đủ vào bản báo cáo
Đơn yêu cầu bảo trì được coi như cơ sở để đề ra kế hoạch của công việc bảotrì Ngoài ra trong nội bộ công ty phần mềm một bản báo cáo thay đổi phần mềmcũng được tạo ra Nó thể hiện công sức cần có để thỏa mãn một đơn yêu cầu bảo trì,trạng thái ban đầu của yêu cầu sửa đổi, các dữ liệu cần cho việc sửa đổi…
5.2.3 Lưu giữ các hồ sơ
Các thông tin cần phải lưu giữ trong hồ sơ bảo trì thường:
Dấu hiệu nhận biết chương trình
Số lượng các câu lệnh trong chương trình nguồn
Số lượng các lệnh mã máy
Ngôn ngữ lập trình được sử dụng
Ngàycài đặt chương trình
Số các chương trình chạy từ khi cài đặt
Số các lỗi xử lý xảy ra
Mức và dấu hiệu thay đổi chương trình
Số các câu lệnh được thêm vào chương trình nguồn khi chương trình thay đổi
Số các câu lệnh được xóa khỏi chương trình nguồn khi chương trình thay đổi
Số giờ mỗi người sử dụng cho mỗi lần sửa đổi
Ngày thay đổi chương trình
Dấu hiệu của kỹ sư phần mềm
Dấu hiệu của đơn yêu cầu bảo trì
Kiểu bảo trì