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

Bảo trì phần mềm được chấp nhận rộng rãi một phần của SDLC bây giờ một ngày. 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 phân phối 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ố trong số đó được đề cập ngắn gọn dưới đây:

Market Conditions - 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 áp dụng như, cách duy trì sổ sách kế toán, có thể kích hoạt nhu cầu sửa đổi.
Client Requirements - 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.
Host Modifications - 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ủ đích thay đổi, thì cần thay đổi phần mềm để duy trì khả năng thích ứng.
Organization Changes - Nếu có bất kỳ sự thay đổi cấp độ nghiệp vụ nào ở phía khách hàng, chẳng hạn như giảm sức mạnh tổ chức, mua lại công ty khác, tổ chức mạo hiểm 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 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ỳ khi 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:

Corrective Maintenance - Đ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 sự cố do người dùng phát hiện hoặc kết luận bởi báo cáo lỗi của người dùng.
Adaptive Maintenance - Đ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 luôn cập nhật và phù hợp với thế giới công nghệ và môi trường kinh doanh luôn thay đổi.
Perfective Maintenance- Đ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, các yêu cầu mới của người dùng để tinh chỉnh phần mềm và cải thiện độ tin cậy và hiệu suất của nó.
Preventive Maintenance- Đ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 đề, hiện không đáng kể 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 thấy 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 trình quy trình phần mềm.

Trung bình, chi phí bảo trì phần mềm là hơn 50% của 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à lên đến 10 đến 15 năm.
Các phần mềm cũ hơn, vốn có nghĩa là hoạt động trên các máy chậm với ít bộ nhớ và dung lượng lưu trữ hơn không thể tự thách thức các phần mềm nâng cao mới 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ì 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 tiếp theo nào.
Các thay đổi thường không được ghi lại có thể gây ra nhiều xung đột hơn trong tương lai.

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

Cấu trúc của 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 song hành với từng giai đoạn sau:

Identification & Tracing- 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 ra bởi người dùng hoặc hệ thống có thể tự báo cáo thông qua nhật ký hoặc thông báo lỗi. Ở đây, kiểu bảo trì cũng được phân loại.
Analysis- 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 thông số kỹ thuật yêu cầu. Chi phí sửa đổi / bảo trì được phân tích và kết luận ước tính.
Design- 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 đã đặt ra ở giai đoạn trước. Các trường hợp thử nghiệm được tạo ra để xác nhận và xác minh.
Implementation - 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 ra trong bước thiết kế. Mỗi lập trình viên phải thực hiện kiểm thử đơn vị song song.
System Testing- 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 tra 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ể, theo các quy trình kiểm tra hồi quy.
Acceptance Testing- Sau khi chạy thử nội bộ hệ thống được nghiệm thu với sự trợ giúp của người dùng. Nếu ở trạng thái này, người dùng khiếu nại 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 tiếp theo.
Delivery- Sau khi kiểm tra nghiệm thu, 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 ở cuối máy khách sau khi phần mềm được chuyển giao.

Cơ sở đào tạo được cung cấp nếu cần thiết, ngoài bản cứng của hướng dẫn sử dụng.
Maintenance management- 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, quản lý bán phiên bản hoặc vá lỗi.

Tái thiết kế phần mềm

Khi chúng ta cần cập nhật phần mềm để phù hợp với 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 thiết kế 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 cũ 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ở nên đau đầu. Ngay cả khi phần mềm già đi theo thời gian, chức năng của nó vẫn 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 trong hợp ngữ rất khó.

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

Tái thiết kế quy trình

Decidenhững gì để thiết kế lại. Nó là toàn bộ phần mềm hay một phần của nó?
Perform Reverse Engineering, để có được thông số kỹ thuật của phần mềm hiện có.
Restructure Programnếu được yêu cầu. Ví dụ, thay đổi chương trình hướng chức năng thành chương trình hướng đối tượng.
Re-structure data theo yêu cầu.
Apply Forward engineering khái niệm để 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 kỹ thuật lại phần mềm

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

Nó 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 xem là mô hình SDLC đảo ngược, tức là chúng ta 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à thiết kế đã được triển khai trước đó, 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

Nó 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ó. Tất cả là về việc sắp xếp lại mã nguồn, trong cùng một ngôn ngữ lập trình hoặc từ một ngôn ngữ lập trình này sang một ngôn ngữ lập trình khác. Tái cấu trúc có thể có tái cấu trúc mã nguồn và tái cấu trúc dữ liệu hoặc cả hai.

Việc 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 cấu trúc lại.

Sự 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.

Kỹ thuật chuyển tiếp

Kỹ thuật chuyển tiếp là một quá trình thu được phần mềm mong muốn từ các thông số kỹ thuật trong tay đã được đưa xuống bằng kỹ thuật đảo ngược. Nó giả định rằng đã có một số kỹ thuật 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 quá trình thiết kế ngược.

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

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 con.

Thí dụ

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

Các thành phần có tính gắ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 nhiệm 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ể cho mối quan tâm của họ và có ít 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 nhiều 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 tái sử dụng 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 ở nhiều cấp độ khác nhau

Application level - Nơi toàn bộ ứng dụng được sử dụng như hệ thống con của phần mềm mới.
Component level - Hệ thống con của một ứng dụng được sử dụng ở đâu.
Modules level - 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.

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

Có thể áp dụng hai loại phương pháp: hoặc 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ữ cho các thành phần giống nhau và sửa đổi các yêu cầu.

Requirement Specification - Các yêu cầu chức năng và phi chức năng được chỉ định, mà sản phẩm phần mềm phải tuân theo, 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.
Design- Đâ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.
Specify Components - 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 nhỏ hơn hoặc hệ thống con. Một thiết kế phần mềm hoàn chỉnh biến thành một tập hợp các thành phần khổng lồ hoạt động cùng nhau.
Search Suitable Components - Kho lưu trữ thành phần phần mềm được các nhà thiết kế tham khảo để 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.
Incorporate Components - Tất cả các thành phần phù hợp được đóng gói với nhau để định hình chúng như một phần mềm hoàn chỉnh.