Tổng quan về bảo trì phần mềm

Ngày nay, bảo trì phần mềm được chấp nhận rộng rãi trong SDLC. Nó là viết tắt của tất cả các sửa đổi và cập nhật được thực hiện sau khi chuyển giao sản phẩm phần mềm. Có một số lý do tại sao cần phải sửa đổi, một số lý do được đề cập ngắn gọn dưới đây:

Điều kiện thị trường – Các chính sách thay đổi theo thời gian, chẳng hạn như thuế và các ràng buộc mới được đưa ra như cách duy trì sổ sách kế toán, có thể dẫn đến nhu cầu sửa đổi.
Yêu cầu của khách hàng – Theo thời gian, khách hàng có thể yêu cầu các tính năng hoặc chức năng mới trong phần mềm.
Sửa đổi máy chủ – Nếu bất kỳ phần cứng và/hoặc nền tảng nào (chẳng hạn như hệ điều hành) của máy chủ mục tiêu thay đổi, thì cần phải thay đổi phần mềm để duy trì khả năng thích ứng.
Thay đổi về tổ chức – Nếu có bất kỳ thay đổi nào ở cấp độ kinh doanh ở phía khách hàng, chẳng hạn như giảm sức mạnh của tổ chức, mua lại một công ty khác, tổ chức mạo hiểm tham gia vào hoạt động kinh doanh mới, có thể phát sinh nhu cầu sửa đổi trong phần mềm gốc.

Các loại bảo trì

Trong vòng đời của phần mềm, loại hình bảo trì có thể khác nhau tùy theo bản chất của nó. Nó có thể chỉ là một nhiệm vụ bảo trì định kỳ do một số lỗi được phát hiện bởi một số người dùng hoặc bản thân nó có thể là một sự kiện lớn dựa trên quy mô hoặc tính chất bảo trì. Sau đây là một số loại bảo trì dựa trên đặc điểm của chúng:

Bảo trì khắc phục – Điều này bao gồm các sửa đổi và cập nhật được thực hiện để sửa chữa hoặc khắc phục các sự cố do người dùng phát hiện hoặc do các báo cáo lỗi của người dùng kết luận.
Bảo trì thích ứng – Điều này bao gồm các sửa đổi và cập nhật được áp dụng để giữ cho sản phẩm phần mềm được cập nhật và điều chỉnh theo thế giới công nghệ và môi trường kinh doanh luôn thay đổi.
Bảo trì hoàn hảo – Điều này bao gồm các sửa đổi và cập nhật được thực hiện để giữ cho phần mềm có thể sử dụng được trong thời gian dài. Nó bao gồm các tính năng mới, yêu cầu người dùng mới để tinh chỉnh phần mềm và cải thiện độ tin cậy cũng như hiệu suất của nó.
Bảo trì phòng ngừa – Điều này bao gồm các sửa đổi và cập nhật để ngăn chặn các sự cố trong tương lai của phần mềm. Nó nhằm mục đích giải quyết các vấn đề không đáng kể tại thời điểm này nhưng có thể gây ra các vấn đề nghiêm trọng trong tương lai.

Chi phí bảo trì

Các báo cáo cho rằng chi phí bảo trì cao. Một nghiên cứu về ước tính bảo trì phần mềm cho thấy chi phí bảo trì cao tới 67% chi phí của toàn bộ chu kỳ quy trình phần mềm.

Trung bình, chi phí bảo trì phần mềm chiếm hơn 50% trong tất cả các giai đoạn SDLC. Có nhiều yếu tố khác nhau khiến chi phí bảo trì tăng cao, chẳng hạn như:

Các yếu tố trong thế giới thực ảnh hưởng đến chi phí bảo trì

Độ tuổi tiêu chuẩn của bất kỳ phần mềm nào được coi là từ 10 đến 15 năm.
Các phần mềm cũ hơn, được thiết kế để hoạt động trên các máy chậm với bộ nhớ và dung lượng lưu trữ ít hơn, không thể tự thách thức các phần mềm cải tiến mới sắp ra mắt trên phần cứng hiện đại.
Khi công nghệ tiến bộ, việc duy trì phần mềm cũ trở nên tốn kém.
Hầu hết các kỹ sư bảo trì đều là người mới và sử dụng phương pháp thử và sai để khắc phục sự cố.
Thông thường, những thay đổi được thực hiện có thể dễ dàng làm hỏng cấu trúc ban đầu của phần mềm, gây khó khăn cho bất kỳ thay đổi nào sau đó.
Các thay đổi thường không được ghi lại, điều này có thể gây ra nhiều xung đột hơn trong tương lai.

Các yếu tố phần mềm cuối ảnh hưởng đến chi phí bảo trì

Cấu trúc chương trình phần mềm
Ngôn ngữ lập trình
Sự phụ thuộc vào môi trường bên ngoài
Độ tin cậy và tính sẵn sàng của nhân viên

Hoạt động bảo trì

IEEE cung cấp một khuôn khổ cho các hoạt động quy trình bảo trì tuần tự. Nó có thể được sử dụng theo cách lặp đi lặp lại và có thể được mở rộng để có thể bao gồm các mục và quy trình tùy chỉnh.

Các hoạt động này đi đôi với nhau trong từng giai đoạn sau:

Xác định & Truy tìm – Nó liên quan đến các hoạt động liên quan đến việc xác định yêu cầu sửa đổi hoặc bảo trì. Nó được tạo bởi người dùng hoặc hệ thống có thể tự báo cáo qua nhật ký hoặc thông báo lỗi. Ở đây, loại bảo trì cũng được phân loại.
Phân tích – Việc sửa đổi được phân tích về tác động của nó đối với hệ thống bao gồm các tác động về an toàn và bảo mật. Nếu tác động có thể xảy ra là nghiêm trọng, giải pháp thay thế sẽ được tìm kiếm. Một tập hợp các sửa đổi cần thiết sau đó được cụ thể hóa thành các đặc tả yêu cầu. Chi phí sửa đổi/bảo trì được phân tích và ước tính được kết luận.
Thiết kế – Các mô-đun mới, cần được thay thế hoặc sửa đổi, được thiết kế dựa trên các thông số kỹ thuật yêu cầu được đặt trong giai đoạn trước. Các trường hợp thử nghiệm được tạo để xác nhận và xác minh.
Triển khai – Các mô-đun mới được mã hóa với sự trợ giúp của thiết kế có cấu trúc được tạo trong bước thiết kế. Mọi lập trình viên đều phải thực hiện kiểm thử đơn vị song song.
Kiểm tra hệ thống – Kiểm tra tích hợp được thực hiện giữa các mô-đun mới được tạo. Kiểm thử tích hợp cũng được thực hiện giữa các mô-đun mới và hệ thống. Cuối cùng, hệ thống được kiểm tra tổng thể, tuân theo quy trình kiểm tra hồi quy.
Kiểm tra chấp nhận – Sau khi kiểm tra nội bộ hệ thống, hệ thống sẽ được kiểm tra để chấp nhận với sự trợ giúp của người dùng. Nếu ở trạng thái này, người dùng phàn nàn về một số vấn đề mà họ đã được giải quyết hoặc lưu ý để giải quyết trong lần lặp lại tiếp theo.
Phân phối – Sau khi kiểm tra chấp nhận, hệ thống được triển khai trên toàn tổ chức bằng gói cập nhật nhỏ hoặc cài đặt mới hệ thống. Thử nghiệm cuối cùng diễn ra ở phía khách hàng sau khi phần mềm được chuyển giao.

Cơ sở đào tạo được cung cấp nếu cần, ngoài bản cứng hướng dẫn sử dụng.

Quản lý bảo trì – Quản lý cấu hình là một phần thiết yếu của bảo trì hệ thống. Nó được hỗ trợ với các công cụ kiểm soát phiên bản để kiểm soát các phiên bản, bán phiên bản hoặc quản lý bản vá.

Tái kỹ nghệ phần mềm

Khi chúng ta cần cập nhật phần mềm để giữ nó ở thị trường hiện tại mà không ảnh hưởng đến chức năng của nó, nó được gọi là tái kỹ nghệ phần mềm. Đó là một quá trình kỹ lưỡng trong đó thiết kế của phần mềm được thay đổi và các chương trình được viết lại.

Phần mềm kế thừa không thể tiếp tục điều chỉnh với công nghệ mới nhất hiện có trên thị trường. Khi phần cứng trở nên lỗi thời, việc cập nhật phần mềm trở thành vấn đề đau đầu. Ngay cả khi phần mềm cũ đi theo thời gian, chức năng của nó thì không.

Ví dụ, ban đầu Unix được phát triển bằng hợp ngữ. Khi ngôn ngữ C ra đời, Unix được thiết kế lại bằng C, vì làm việc bằng hợp ngữ rất khó.

Ngoài điều này, đôi khi các lập trình viên nhận thấy rằng một số phần của phần mềm cần bảo trì nhiều hơn những phần khác và chúng cũng cần tái kỹ nghệ.

Quy trình tái kỹ thuật

Quyết định những gì cần thiết kế lại. Đó là toàn bộ phần mềm hay một phần của nó?
Thực hiện Kỹ thuật đảo ngược, để có được thông số kỹ thuật của phần mềm hiện có.
Cơ cấu lại chương trình nếu cần. Ví dụ, thay đổi chương trình hướng hàm thành chương trình hướng đối tượng.
Cấu trúc lại dữ liệu theo yêu cầu.
Áp dụng các khái niệm kỹ thuật Chuyển tiếp để có được phần mềm được thiết kế lại.

Có một số thuật ngữ quan trọng được sử dụng trong Tái kỹ nghệ phần mềm

Kỹ thuật đảo ngược

Đó là một quá trình để đạt được đặc tả hệ thống bằng cách phân tích kỹ lưỡng, hiểu rõ hệ thống hiện có. Quá trình này có thể được coi là mô hình SDLC ngược, tức là chúng tôi cố gắng đạt được mức độ trừu tượng cao hơn bằng cách phân tích các mức độ trừu tượng thấp hơn.

Một hệ thống hiện có là một thiết kế đã được triển khai trước đây mà chúng ta không biết gì về nó. Sau đó, các nhà thiết kế thực hiện kỹ thuật đảo ngược bằng cách xem mã và cố gắng lấy thiết kế. Với thiết kế trong tay, họ cố gắng kết luận các thông số kỹ thuật. Do đó, đi ngược lại từ mã đến đặc tả hệ thống.

Tái cấu trúc chương trình

Đó là một quá trình tái cấu trúc và xây dựng lại phần mềm hiện có. Đó là tất cả về việc sắp xếp lại mã nguồn, bằng cùng một ngôn ngữ lập trình hoặc từ ngôn ngữ lập trình này sang ngôn ngữ lập trình khác. Tái cấu trúc có thể bao gồm tái cấu trúc mã nguồn và tái cấu trúc dữ liệu hoặc cả hai.

Tái cấu trúc không ảnh hưởng đến chức năng của phần mềm nhưng nâng cao độ tin cậy và khả năng bảo trì. Các thành phần chương trình thường gây ra lỗi có thể được thay đổi hoặc cập nhật bằng cách tái cấu trúc.

Độ tin cậy của phần mềm trên nền tảng phần cứng lỗi thời có thể được loại bỏ thông qua tái cấu trúc.

Chuyển tiếp kỹ thuật

Kỹ thuật chuyển tiếp là một quá trình để có được phần mềm mong muốn từ các thông số kỹ thuật có sẵn đã được đưa xuống bằng kỹ thuật đảo ngược. Nó giả định rằng đã có một số công nghệ phần mềm đã được thực hiện trong quá khứ.

Kỹ thuật chuyển tiếp cũng giống như quy trình kỹ thuật phần mềm chỉ có một điểm khác biệt – nó luôn được thực hiện sau kỹ thuật đảo ngược.

khả năng tái sử dụng thành phần

Một thành phần là một phần của mã chương trình phần mềm, thực thi một tác vụ độc lập trong hệ thống. Nó có thể là một mô-đun nhỏ hoặc chính hệ thống phụ.

Ví dụ

Các thủ tục đăng nhập sử dụng trên web có thể coi là các thành phần, hệ thống in trong phần mềm có thể xem như một thành phần của phần mềm.

Các thành phần có tính liên kết cao về chức năng và tỷ lệ ghép nối thấp hơn, tức là chúng hoạt động độc lập và có thể thực hiện các tác vụ mà không phụ thuộc vào các mô-đun khác.

Trong OOP, các đối tượng được thiết kế rất cụ thể đối với mối quan tâm của chúng và ít có cơ hội được sử dụng trong một số phần mềm khác.

Trong lập trình mô-đun, các mô-đun được mã hóa để thực hiện các tác vụ cụ thể có thể được sử dụng trên một số chương trình phần mềm khác. Có một ngành dọc hoàn toàn mới, dựa trên việc sử dụng lại thành phần phần mềm và được gọi là Kỹ thuật phần mềm dựa trên thành phần (CBSE).

Tái sử dụng có thể được thực hiện ở các cấp độ khác nhau

Cấp ứng dụng – Nơi toàn bộ ứng dụng được sử dụng làm hệ thống con của phần mềm mới.
Cấp độ thành phần – Nơi sử dụng hệ thống con của ứng dụng.
Cấp độ mô-đun – Nơi các mô-đun chức năng được sử dụng lại.

Các thành phần phần mềm cung cấp các giao diện, có thể được sử dụng để thiết lập giao tiếp giữa các thành phần khác nhau.

Quá trình tái sử dụng

Hai loại phương pháp có thể được áp dụng: bằng cách giữ nguyên các yêu cầu và điều chỉnh các thành phần hoặc bằng cách giữ nguyên các thành phần và sửa đổi các yêu cầu.

Đặc tả yêu cầu – Các yêu cầu chức năng và phi chức năng được chỉ định, mà một sản phẩm phần mềm phải tuân thủ, với sự trợ giúp của hệ thống hiện có, đầu vào của người dùng hoặc cả hai.
Thiết kế – Đây cũng là một bước quy trình SDLC tiêu chuẩn, trong đó các yêu cầu được xác định theo cách nói của phần mềm. Kiến trúc cơ bản của toàn bộ hệ thống và các hệ thống con của nó được tạo ra.
Chỉ định các thành phần – Bằng cách nghiên cứu thiết kế phần mềm, các nhà thiết kế tách toàn bộ hệ thống thành các thành phần hoặc hệ thống con nhỏ hơn. Một thiết kế phần mềm hoàn chỉnh trở thành một tập hợp gồm một tập hợp lớn các thành phần hoạt động cùng nhau.
Tìm kiếm các thành phần phù hợp – Kho lưu trữ thành phần phần mềm được các nhà thiết kế giới thiệu để tìm kiếm thành phần phù hợp, trên cơ sở chức năng và các yêu cầu phần mềm dự kiến..
Kết hợp các thành phần – Tất cả các thành phần phù hợp được đóng gói cùng nhau để định hình chúng thành phần mềm hoàn chỉnh.