Công nghệ phần mềm quy trình bảo trì phần mềm

30 2.7K 5
Công nghệ phần mềm quy trình bảo trì phần mềm

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

Thông tin tài liệu

TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM HỌ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 Giảng viên: Nguyễn Văn Thắng Sinh viên thực hiện: PhaLiNha Nguyễn Công Đức Nguyễn Tuấn Anh Nguyễn Thị Hồng Ngoan Nguyễn Thu Thùy TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM MỤC LỤC Danh 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 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 2 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM I. 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ôn ngữ 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ây dự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ột phầ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ình phá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ềm là 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ụng trong 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ẩn cho 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ần thự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ủa nó 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ó quy trì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ần mề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ần mề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ủa khách hàng, nâng cấp chương trình. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 3 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM Hì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ần mề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ần mề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ật khi 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ẩn IEEE(1993), thì bảo trì phần mềm được định nghĩa là việc sửa đổi một phần mềm sau 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ềm hoặ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ích thướ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ập trì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ông có 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 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 4 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM hiể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ằng chi 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ộ chi phí 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 quan hệ 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ần mề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ình nà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ếu dẫ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ượng khá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 đến cá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 cho việ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ính xá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 ứng dụ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ột trong 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ần mề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ã nguồn, hay rộng hơn là các giả tưởng(artifact) do chính họ tạo ra nữa. Khó khăn NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 5 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM thậ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ưa nó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. Tuy nhiên, ngay trong những IDE (Integrated Development Environment-môi trường phá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ìm kiế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ông thường theo tên các method, class, …mà không hỗ trợ tìm kiếm kết hợp giữa các thà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ếm cá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ỏa mã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ảo trì 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ệm kiể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àng quá 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ần mề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) NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 6 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM Hì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ác lỗ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 sinh do: • 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ềm hoạt động không còn chính xác, đầy đủ, thậm chí là truyền đạt sai hay những yê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 được kiể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ết kế 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. NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 7 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM 2.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ỉnh sửa phần mềm, làm cho phần mềm hoạt động được bình thường khi có sự thay đổi củ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ên ngoà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àm việ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ị đi kè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ức nă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ì được thự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ệc tiế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ến phươ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àm cả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ùng dẫ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 động nhằ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, ghi chú, 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ằm giả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âng cấ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 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 8 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM • 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ện truyề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êu cầ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 quan trọng, cần phải được thực hiện theo định kỳ để đảm bảo hệ thống hoạt động được liê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ần mề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ông cao, 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 ra sai 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êu cầ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 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 9 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM Mô 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ống hiệ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ên bả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 trong như 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ậm chí 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úc nà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ái sử 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 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 10 [...]... và nó được miêu tả trong chuẩn bảo trì phần mềm IEEE 1291 1998.Mô hình quy trình này bắt đầu với việc cố gắng bảo trì phần mềm trong giai đoạn sau khi giao hàng và các vấn đề thảo luận như kế hoạch bảo trì Bảo trì gồm các công việc sau: • Sửa lỗi • Chỉnh sửa để làm việc với nền tảng mới • Tăng cường cho hệ thống (thêm tính năng, tăng độ an toàn…) • Quy trình bảo trì phần mềm cung cấp các hoạt động và... 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ì • Ngày bắt đầu và kết thúc bảo trì • Tổng số giờ của mỗi người dùng cho việc bảo trì. .. các hoạt động đó, và nó được miêu tả trong chuẩn bảo trì phần mềm IEEE 1291 và ISO/IEC 14764 NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 20 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM 1.1 Chuẩn bảo trì phần mềm IEEE 1291 Hình 8: Các hoạt động trong quy trình bảo trì phần mềm Các giai đoạn trong quá trình bảo trì phần mềm gồm: • Classification & Identification: phân... cam kết đã đặt ra hay không? Quá trình nghiệm thu và bàn giao kết thúc, tiến hành kết thúc hợp đồng NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 29 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM III KẾT LUẬN Trong báo cáo nhóm đã trình bày một cách tổng quan bảo trì phần mềm và quy trình bảo trì phần mềm nói chung cũng như quy trình bảo trì một website cụ thể IV TÀI LIỆ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ình huố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ảo trì 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ềm cũ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. .. lý quá trình bảo trì (maintenance manager) NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 13 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM 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ột tiê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... mỗi người cho một ngôn ngữ lập trình • Thời gian trung bình cho việc bảo trì một đơn yêu cầu bảo trì • Tỷ lệ phần trăm của mỗi kiểu bảo trì Hình dưới là chi phí của từng giai đoạn trong quy trình phát triển phần mềm NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 18 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM Hình 6: Chi phí phát triển phần mềm NHÓM 6 – AT7A – HỌC VIỆN... 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... trữ về việc bảo trì thường không có do cơ quan đó phá sản hay các cơ quan bảo trì là độc lập nhau 5.3 Định giá bảo trì Chi phí bảo trì là rất lớn so với các chi phí khác trong quy trình phát triển phần mềm NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 14 TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM Bảng 1: Tỉ lệ chi phí bảo trì ăm T ỉ lệ chi phí bảo trì( %) > 000... bảo trì/ tổng chi phí phần mềm B ảo trì phần mềm/ n gân sách hệ thống thông tin(tro ng tài sản của 1000 công ty) C hi phí dành E rli kh (2 00 0) E as tw oo d( 19 93 ) M oa d( TÌM HIỂU VỀ BẢO TRÌ PHẦN MỀM VÀ QUY TRÌNH BẢO TRÌ PHẦN MỀM 6 990 070 % 988 070 % 6 6 984 575 % NHÓM 6 – AT7A – HỌC VIỆN KỸ THUẬT MẬT MÃPage 16 cho phát triển và bảo trì/ tổng chi phí phần mềm B ảo trì phần mềm/ n

Ngày đăng: 21/08/2014, 14:17

Từ khóa liên quan

Mục lục

  • 4.1. Mô hình Quick-Fix

  • 4.2. Mô hình Iterative Enhancement

  • 4.3. Mô hình Full-reuse

    • 5.1.1 Yếu tố kiểm soát

    • 5.1.2 Đánh giá định lượng

    • 5.2.1 Cơ cấu bảo trì

    • 5.2.2 Báo cáo

    • 5.2.3 Lưu giữ các hồ sơ

    • 1.1. Chuẩn bảo trì phần mềm IEEE 1291

      • 1.1.1 Xác định vấn đề, phân loại và ưu tiên

        • 1.1.1.1. Đầu vào

        • 1.1.1.2. Quá trình thực hiện

        • 1.1.1.3. Đầu ra

        • 1.1.2. Phân tích

          • 1.1.2.1. Đầu vào

          • 1.1.2.2. Quá trình thực hiện

          • 1.1.2.3. Đầu ra

          • 1.1.3. Thiết kế

            • 1.1.3.1. Đầu vào

            • 1.1.3.2. Quá trình thực hiện

            • 1.1.3.3. Đầu ra

            • 1.1.4. Cài đặt

              • 1.1.4.1. Đầu vào

              • 1.1.4.2. Quá trình thực hiện

              • 1.1.4.3. Đầu ra

              • 1.1.5. Kiểm thử hệ thống

                • 1.1.5.1. Đầu vào

Tài liệu cùng người dùng

Tài liệu liên quan