Bảo trì phần mềm

Các thuật ngữ:

• MR (modification request): yêu cầu chỉnh sửa.
• PR (problem report): báo cáo các vấn đề.
• SCM (software configuration management): quản lý cấu hình phần mềm.
• SLA (service level agreement): thỏa thuận dịch vụ theo cấp độ.
• SQA (software quality assurance): quản lý chất lượng phần mềm.
• V&V (verification and validation): xác minh và thẩm định.
• Predelivery: Trước khi bàn giao
• Postdelivery: Sau khi phân phối

Giới thiệu

Nỗi lực phát triển phần mềm dẫn tới khi chuyển giao sản phẩm phải thỏa mãn yêu cầu của khách hàng. Theo đó các sản phẩm phần mềm phải thay đổi và phát triển. Sau khi hoạt động, các lỗi được phát hiện, môi trường hoạt động thay đổi và yêu cầu người dùng mới phát sinh. Giai đoạn bảo trì trong vòng đời phát triển của phần mềm sẽ bắt đầu sau thời gian bảo hành, hoặc sau khi bàn giao sản phẩm, nhưng đa phần hoạt động này sẽ xảy ra sớm hơn. Bảo trì phần mềm là một phần không thể thiếu trong vòng đời phần mềm. Trong lịch sử, phát triển phần mềm được đánh giá cao hơn nhiều so với bảo trì phần mềm trong hầu hết các tổ chức. Điều này đang thay đổi, các tổ chức đã đầu tư vào khâu phát triển phần mềm của họ bằng cách giữ cho phần mềm của họ hoạt động càng lâu càng tốt. Trong tài liệu này, bảo trì phần mềm được xác định là toàn bộ các hoạt động cần thiết để cung cấp sự hỗ trợ một cách hiệu quả về chi phí cho phần mềm. Các hoạt động được thực hiện trong giai đoạn trước khi bàn giao cũng như trong giai đoạn sau khi bàn giao. Hoạt động trước khi bàn giao bao gồm lập kế hoạch cho các hoạt động sau khi bàn giao, bảo trì, và hậu cần xác định các hoạt động chuyển đổi. Hoạt động sau khi bàn giao bao gồm chỉnh sửa phần mềm, trainning, điều hành hoặc tương tác. Kiến thức về lĩnh vực bảo trì phần mềm liên quan tới tất cả các khía cạnh khác của kỹ thuật phần mềm. Do đó, tài liệu này được liên kết tới tất cả các lĩnh vực khác trong bảo trì phần mềm.

1. Cơ bản về bảo trì phần mềm

Mục đầu tiên giới thiệu các khái niệm và thuật ngữ cái mà hình thành một nền tảng cơ bản để hiểu rõ vai trò phạm vi của bảo trì phần mềm. Các chủ đề cung cấp khái niệm và nhấn mạnh lý do tại sao phần mềm phải có nhu cầu bảo trì. Phân loại bảo trì phần mềm là rất quan trọng để hiểu được ý nghĩa của nó.

1.1 Định nghĩa và thuật ngữ

Mục đích của bảo trì phần mềm được định nghĩa theo các tiêu chuẩn quốc tế về bảo trì: trong bối cảnh của công nghệ phần mềm, bảo trì phần mềm cơ bản là một trong nhiều quy trình kĩ thuật. Mục tiêu của bảo trì phần mềm là sửa đổi phần mềm hiện có trong khi vẫn đảm bảo toàn vẹn. Các chuẩn quốc tế cũng khẳng định tầm quan trọng của việc nên có một vài hoạt động bảo trì nên xảy ra trước khi bàn giao sản phẩm.

1.2 Bản chất của bảo trì phần mềm

Bảo trì phần mềm duy trì các sản phẩm phần mềm trong suốt vòng đời của nó (từ phát triển đến hoạt động). Yêu cầu sửa đổi được đăng nhập và theo dõi, các tác động của những thay dổi được xác định, code và sản phẩm sau khi được sửa đổi, thử nghiệm được tiến hành và một phiên bản mới của các sản phẩm được phát hành. Ngoài ra, tập huấn và hỗ trợ thường xuyên sẽ được cung cấp cho người sử dụng. Những người bảo trì được định nghĩa giống như một tổ chức thực hiện các hoạt động bảo trì; đôi khi sẽ đề cập đến những cá nhân thực hiện các hoạt động khác hẳn với các nhà phát triển. IEEE 14.764 xác định các hoạt động chính của bảo trì phần mềm giống như thực thi các quy trình, phân tích các lỗi và chỉnh sửa, thực thi chỉnh sửa, kiểm định, tích hợp hoặc loại bỏ. Các hoạt động này được thảo luận tại mục 3.2 – hoạt động bảo trì.

Bảo trì có thể học hỏi các kiến thức từ các nhà phát triển phần mềm. Liên hệ với những nhà phát triển và sự tham gia từ đầu của các nhà phát triển sẽ làm giảm nỗ lực bảo trì tổng thể. Trong một số trường hợp, các nhà phát triển ban đầu không thể hợp tác hoặc đã chuyển sang nhiệm vụ khác, vấn đề này sẽ tạo ra thách thức cho bảo trì. Bảo trì phải mất nhiều sản phẩm (artifacts) (ví dụ source code, tài liệu ...) từ các nhà phát triển hoặc phải hỗ trợ ngay lập tức, sau đấy dần dần tự phát triển và duy trì chúng trong một vòng đời phần mềm.

1.3 Sự cần thiết của bảo trì phần mềm

Bảo trì là cần thiết để đảm bảo rằng phần mềm có thể tiếp tục đáp ứng yêu cầu của người sử dụng. Bảo trì được áp dụng cho phần mềm bằng cách sử dụng bất kì mô hình vòng đời phần mềm (ví dụ: xoắn ốc, tuyến tính,…). Sản phẩm phần mềm thay đổi do hoạt động chỉnh sửa sai hoặc không sai.Bảo trì phần mềm phải được thực hiện để:

• Khắc phục lỗi.
• Cải thiện thiết kế.
• Thực hiện các cải tiến.
• Giao diện với các phần mềm khác.
• Thích ứng với các loại phần cứng, phần mềm, tính năng hệ thống,…khác nhau có thể được sử dụng.
• Tiến hóa phần mềm.
• Hủy bỏ phần mềm.

5 đặc điểm chính bao gồm các hoạt động của người bảo trì bao gồm:

• Duy trì kiểm soát các chức năng của phần mềm liên tục.
• Duy trì kiểm soát việc sửa đổi phần mềm.
• Hoàn thiện các chức năng hiện có.
• Xác định các mối đe dọa an ninh và sửa chữa các lỗ hổng an ninh.
• Ngăn ngừa việc xuống cấp hiệu xuất tới mức không thể chấp nhận được.

1.4. Chi phí bảo trì

Bảo trì tiêu thụ một phần lớn các nguồn lực tài chính trong vòng đời phần mềm. Một nhận thức chung về bảo trì thường thấy: bảo trì đơn thuần là sửa lỗi. Tuy nhiên, các nghiên cứu và khảo sát trong những năm qua đã chỉ ra rằng phần lới, trên 80%, bảo trì phần mềm được sử dụng cho các hành động khắc phục. Nhóm các cải tiến và sửa chữa lại với nhau trong báo cáo quản lý góp phần tạo ra các quan niệm sai lầm về chi phí cao của việc sửa chữa. Hiểu biết về các loại bảo trì phần mềm giúp hiểu được cơ cấu của chi phí bảo trì. Ngoài ra, có kiến thức về các yếu tổ ảnh hưởng tới bảo trì phần mềm sẽ giúp quản lý được chi phí. Một số yếu tố môi trường và mối quan hệ ảnh hưởng tới chi phí bảo trì phần mềm:

• Môi trường hoạt động liên quan đến phần cứng và phần mềm.
• Môi trường tổ chức liên quan đến chính sách, tính cạnh tranh, quy trình, sản p ẩm và nhân viên.

1.5. Sự tiến hóa của phần mềm

Quá trình tiến hóa của phần mềm đã được đề cập tới lần đầu tiên vào cuối năm 1960s. Trong khoảng thời gian hai mươi năm, nghiên cứu đưa đến việc xây dựng “Law of Evolution”. Những phát hiện chính bao gồm một đề nghị đó là duy trì phát triển, tiến hóa, và quyết định bảo dưỡng được hỗ trợ bởi sự thu thập kiến thức về hoạt động của phần mềm theo thời gian. Một số trạng thái được tiếp tục duy trì phát triển, nói cách khác, hiện tại phần mềm lớn không bao giờ là hoàn thành, và nó liên tục phát triển; nó trở nên phức tạp hơn, trừ khi một số hành động được thực hiện để giảm sự phức tạp này.

1.6. Phân loại bảo trì phần mềm

Có ba loại bảo trì được xác định: corrective (điều chỉnh, sửa chữa), adaptive (thích ứng), và perfective (hoàn thiện). Ngoài ra còn có preventative (dự phòng).

• Bảo trì sửa chữa: sửa đổi phản ứng (hoặc sửa chữa) một sản phẩm phần mềm thực hiện sau khi bàn giao để chỉnh sửa các vấn đề được phát hiện. Trong loại này, bảo trì là khẩn cấp, một thay đổi đột xuất thực hiện.
• Bảo trì thích ứng: sửa đổi một sản phẩm phần mềm được thực thi sau khi bàn giao, phần mềm muốn chuyển đổi môi trường. Ví dụ như: nâng cấp hệ điều hành, khi đấy việc nâng cấp phần mềm là cần thiết.
• Bảo trì hoàn thiện: sửa đổi một sản phẩm phần mềm sau khi bàn giao để cung cấp cải tiến cho người dùng, cải thiện tài liệu chương trình, và viết lại mã để cải thiện hiệu suất phần mềm, bảo trì, hoặc các thuộc tính phần mềm khác.
• Bảo trì dự phòng: sửa đổi một sản phẩm phần mềm sau khi tìm thấy các lỗi tiềm ẩn trong sản phẩm phần mềm trước khi lỗi hoạt động.

2. Các vấn đề chính trong bảo trì phần mềm

Một số vấn đề quan trọng phải được xử lý để đảm bảo duy trì hiệu quả của phần mềm. Bảo trì phần mềm cung cấp các thách thức độc lập về kỹ thuật và quản lý cho các ký sư phần mềm. ví dụ: cố gắng tìm được một lỗi trong phần mềm có chứa lượng lớn các dòng code của nhà phát triển. Tương tự như vậy, cạnh tranh với những nhà phát triển giống như một trận chiến liên tục. Lập kế hoạch cho một tương lai phát hành sản phẩm, thường bao gồm code cho tới khi tạo ra các bản vá lỗi cho phiên bản hiện tại, cũng tạo ra một thách thức. Phần sau đây trình bày một số vấn đề kỹ thuật và quản lý liên quan tới bảo trì phần mềm. Họ đã được nhóm lại theo các chủ đề sau:

• Vấn đề kĩ thuật
• Vấn đề quản lý
• Ước lượng chi phí
• Đo lường

2.1 Vấn đề kĩ thuật

2.1.1 Giới hạn về hiểu biết

Hiểu biết hạn chế, đề cập đến một cách nhanh chóng, kỹ sư phần mềm có thể hiểu được để có thể thay đổi hoặc sửa chữa lỗi trong phần mềm, cái mà họ phát triển. Nghiên cứu chỉ ra rằng, khoảng một nửa tổng nỗ lực được duy trình dành hết cho tìm hiểu phần mềm phải sửa đổi. Như vậy, chủ đề này là mối quan tâm lớn cho các kĩ sư phần mềm. Vì vậy, thời điểm đầu, kĩ sư phần mềm thường có hiểu biết tương đối hạn chế về phần mềm.

2.1.2 Kiểm thử

Chi phí để lặp đi lặp lại kiểm tra phần mềm chiếm phần lớn thời gian và tiền bạc. Để đảm bảo rằng, các yêu cầu báo cáo vấn đề là hợp lệ, những nhà bảo trì nên tái tạo hoặc xác minh vấn đề bằng cách chạy thử nghiệm. Kiểm tra hồi quy (các lần kiểm tra lại để xác minh sửa đổi không gây ra tác dụng không mong muốn) là một khái niệm kiểm thử quan trọng trong bảo trì. Ngoài ra, thời gian tìm kiếm để kiểm tra là một vấn đề rất khó khăn. Phối hợp kiểm thử khi các thành viên trong đội bảo trì đang làm các công việc khác nhau vẫn còn là một thách thức. Khi phần mềm thực hiện các chức năng quan trọng, nó khó có thể offline để thực hiện kiểm thử. Kiểm thử không thể thực hiện trong môi trường có ý nghĩa sản xuất nhất định. Kiến thức kiểm thử cung cấp thêm thông tin và tài liệu tham khảo về vấn đề này trong chủ đề phụ của nó dựa trên kiểm thử hồi quy.

2.1.3 Phân tích tác động

Phân tích tác động mô tả cách tiến hành, chi phí, một cách phân tích đầy đủ về tác động của sự thay đổi trong phần mềm hiện có. Bảo trì phải có một kiến thức sâu sắc và nội dung của phần mềm. Họ sử dụng kiến thức đó để thực hiện các phân tích tác động, trong đó xác định tất cả các hệ thống và sản phẩm phần mềm bị ảnh hưởng bởi một yêu cầu thay đổi phần mềm và ước tính chi phi phát triển và các nguồn lực cần thiết để thực hiện các thay đổi. Ngoài ra, nguy cơ làm thay đổi được các quyết định. Các yêu cầu thay đổi, đôi khi được gọi là một yêu cầu sửa đổi (MR) và thường gọi là một bản báo cáo vấn đề (PR), trước tiên phải được phân tích và dịch thành ngôn ngữ phần mềm. Phân tích tác động được thực hiện sau khi một yêu cầu thay đổi đưa vào quy trình quản lý cấu hình. IEEE 14.764 nêu các nhiệm vụ phân tích tác động:

• Phân tích MRs/ PRs.
• Tái tạo hay xác minh các vấn đề.
• Phát triển các tùy chọn để thực hiện sửa đổi.
• Tài liệu hóa MR/PR, kết quả và thực hiện các tùy chọn.
• Chấp thuận cho sửa đổi các tùy chon. Mức độ nghiêm trọng của vấn đề thường được sử dụng để quyết định làm thế nào và khi nào ấn định. Các kĩ sư phần mềm sau đó xác định các thành phần bị ảnh hưởng. Một số giải pháp tiềm năng được cung cấp, tiếp theo đó là một khuyến cáo tốt nhất đưa ra. Phần mềm được thiết kế với khả năng bảo trì trong điều kiện phân tích rất nhiều tác động. Thông tin chi tiết có thể được tìm thấy trong cuốn Software Configuration Management KA.

2.1.4 Bảo trì

IEEE 14.764 định nghĩa bảo trì như là khả năng của các sản phẩm phần mềm có thể sửa đổi. Sửa đổi có thể bao gồm sửa chữa, cải tiến, hoặc áp dụng các phần mềm sao cho phù hợp với các môi trường và chi tiết kĩ thuật chức năng theo yêu cầu. Là một đặc trưng chính trong chất lượng phần mềm, bảo trì nên được chỉ định, xem xét lại, và kiểm soát các hoạt động trong quá trình phát triển phần mềm để giảm chi phí bảo trì. Khi thực hiện thành công, bảo trì phần mềm sẽ được cải thiện. Bảo trì thường khó đạt được vì nó không phải là trọng tâm quan trọng nhất trong quá trình phát triển phần mềm. Các nhà phát triển thông thường sẽ bận rộn với nhiều hoạt động khác và thường xuyên bỏ qua yêu cầu của các bảo trì viên. Điều này thường xuyên xảy ra dẫn đến thiếu tài liệu phần mềm, và môi trường kiểm tra, đó là nguyên nhân hàng đầu của những khó khăn trong đọc hiểu chương trình và phân tích tác động. Sự hiện diện của các quy trình, kỹ thuật, và các công cụ hệ thống sẽ giúp tăng cường khả năng bảo trì phần mềm.

2.2 Vấn đề về quản lý.

2.2.1 Liên kết với các mục tiêu của tổ chức.

Mục tiêu của tổ chức mô tả là làm thế nào để chứng minh được tại sao phải có các hoạt động đầu tư vào bảo trì phần mềm. Phát triển phần mềm ban đầu là thường dựa trên dự án, với quy mô, thời gian và ngân sách xác định. Sự nhấn mạnh chính là cung cấp một sản phẩm đáp ứng nhu cầu của người sử dụng phù hợp về thời gian và ngân sách. Ngược lại, bảo trì phần mềm thường có các mục tiêu là mở rộng vòng đời sống của các phần mềm trở nên càng lâu càng tốt. Ngoài ra, nó có thể được điều khiển bởi sự cần thiết để đáp ứng nhu cầu của người sử dụng khi cập nhật phần mềm và cải tiến. Trong cả 2 trường hợp trên, sự trở lại trên đầu tư sẽ ít nhiều rõ ràng.

2.2.2 Nhân viên

Nhân sự đề cập tới làm thế nào để thu hút và giữ chân các nhân viên bảo trì phần mềm. Bảo trì không phải là thường được xem như một công việc quyến rũ. Như điều tra, nhân viên bảo trì phần mềm chỉ được xem như “công nhân hạng hai” và do đó giảm sút tinh thần.

2.2.3 Quy trình

Các quy trình vòng đời của phần mềm là một tập hợp các hoạt động, phương pháp, cách thực thi và biến đổi, cái mà người sử dụng để phát triển và duy trì phần mềm và các hoạt động liên quan. Ở cấp độ quy trình, phần mềm và các hoạt động bảo trì chia sẻ nhiều điểm chung với việc phát triển (ví dụ, quản lý cấu hình phần mềm là một hoạt động rất quan trọng trong cả 2 hình thức). Bảo trì cũng đòi hỏi một số hoạt động mà không được tìm thấy trong phát triển phần mềm, những hoạt động này là thách thức đối với thực tại quản lý.

2.2.4 Các khía cạnh về tổ chức bảo trì

Khía cạnh tổ chức mô tả làm thế nào để xác định được tổ chức và chức năng sẽ có trách nhiệm bảo trì phần mềm. Các nhóm phát triển phần mềm không nhất thiết phải được giao bảo trì phần mềm khi nó hoạt động. Trong quyết định đâu là nơi mà phần mềm bảo trì, chức năng này sẽ được đặt, ví dụ với phát triển ban đầu đi đến một đội ngũ bảo trì vĩnh viễn (hoặc duy trì), có một đội ngũ bảo trì vĩnh viễn với nhiều lợi ích:

• Cho phép chuyên môn.
• Tạo ra các kênh thông tin liên lạc.
• Thúc đẩy không gian làm việc.
• Giảm sự phụ thuộc vào các cá nhân.
• Cho phép kiểm tra định kì. Vì có rất nhiều ưu điểm và khuyết điểm để lựa chọn, quyết định phải được thực hiện trên từng trường hợp. Phân công trách nhiệm bảo trì là một điều quan trọng, bất kể trong một nhóm đơn lẻ, hoặc trong cơ cấu tổ chức.

2.2.5 Gia công phần mềm

Gia công phần mềm ra nước ngoài để bảo trì đã trở thành một ngành công nghiệp lớn. Các tổ chức đang gia công phần mềm nằm trong danh mục của các nhà đầu tư. Tuy nhiên, thường tùy chọn gia công phần mềm rất ít là phần việc quan trọng vì các công ty không muốn mất kiểm soát cốt lõi kinh doanh của họ trong sản phẩm phần mềm. Một trong những thách thức lớn của gia công phần mềm chính là xác định phạm vi của các dịch vụ bảo dưỡng, các điều khoản thỏa thuận cấp độ dịch vụ và chi tiết trong hợp đồng. Các công ty gia công phải đầu tư cơ sở hạ tầng, và thiết lập hỗ trợ từ xa và phải có những người nói ngôn ngữ bản địa. Gia công phần mềm đòi hỏi một sự đầu tư ban đầu tốt, và thiết lập quy trình bảo trì.

2.3 Ước tính chi phí bảo trì.

Các kĩ sư phần mềm phải hiểu các dạng thức khác nhau của bảo trì phần mềm, thảo luận ở trên, để giải quyết vấn đề ước tính chi phí bảo trì phần mềm. Đối với mục đích lập kế hoạch, dự toán chi phí là một khía cạnh quan trọng của kế hoạch để bảo trì phần mềm.

2.3.1 Ước tính chi phí

Mục 2.1.3 mô tả cách phân tích tác động, xác định tất cả các hệ thống và các sản phẩm phần mềm bị ảnh hưởng bởi một yêu cầu thay đổi phần mềm và ước tính nguồn lực cần thiết để phát triển và thực hiện thay đổi. Dự toán chi phí bảo trì được ảnh hưởng bởi nhiều yếu tố kĩ thuật và không kĩ thuật. IEEE 14.764 cho rằng “hai phương pháp phổ biến nhất để tiếp cận ước tính chi phí và nguồn lực cho bảo trì phần mềm là việc sử dụng các mô hình và sử dụng kinh nghiệm. Một sự kết hợp của hai phương pháp này cũng được sử dụng.

2.3.2 Mô hình tham biến

Mô hình tham biến chi phí (mô hình toán học) đã được áp dụng để bảo trì phần mềm. Có ý nghĩa là dữ liệu lịch sử từ bảo trì đã qua là cần thiết để sử dụng và hiệu chuẩn các mô hình toán học. Thuộc tính điều khiển chi phí ảnh hưởng tới dự toán.

2.3.3 Kinh nghiệm

Kinh nghiệm, trong các hình thức của sự phỏng đoán từ chuyên gia, thường được sử dụng để ước tính chi phí trong nỗ lực bảo trì. Rõ ràng, cách tiếp cận tốt nhất để ước lượng bảo trì là kết hợp các dữ liệu lịch sử và kinh nghiệm. Chi phí để tiến hành sửa đổi (về số lượng của con người và số lượng thời gian). Bảo trì ước lượng dữ liệu lịch sử cần được cung cấp như là một kết quả của phép đo chương trình.

2.4 Đo lường bảo trì phần mềm.

Các đối tượng liên quan đến bảo trì phần mềm, mà thuộc tính có thể bị đo lường bao gồm: các quá trình, tài nguyên và các sản phẩm. Có một số biện pháp phần mềm mà có thể được bắt nguồn từ các thuộc tính của phần mềm, quy trình bảo trì, và nhân viên, bao gồm kích thước, độ phức tạp, chất lượng, tính dễ hiểu, khả năng bảo trì, và công sức (effort). Giải pháp phức tạp của phần mềm cũng có thể thu được bằng cách sử dụng các công cụ thương mại sẵn có. Những biện pháp này tạo thành một điểm khởi đầu tốt cho chương trình đo lường của người bảo trì. Thảo luận về các quy trình phần mềm và đo lường sản phẩm cũng được thể hiện trong tài liệu Software Engineering Process KA. Chủ đề về chương trình đo lường phần mềm được mô tả trong tài liệu Software Engineering Management KA.

2.4.1 Các biện pháp cụ thể

Các nhà bảo trì phải xác định các biện pháp thích hợp cho một tổ chức dựa trên hoàn cảnh riêng của tổ chức đó. Chất lượng phần mềm cho thấy các biện pháp cụ thể để bảo trì. Các biện pháp phụ bao gồm những điều sau đây:

• Phân tích: công sức của các kiểm thử viên hay nguồn lực hoặc để chẩn đoán thiếu sót hoặc nguyên nhân thất bại hoặc để xác định các thành phần phải sửa đổi.
• Tách hay thay đổi: các biện pháp của một kiểm thử viên (measures of the maintainer’s effort) kết hợp với việc thực hiện một quy định sửa đổi.
• Tính ổn định: các biện pháp của các hành vi không mong muốn, trong đó gặp phải tại quá trình kiểm thử.
• Khả năng kiểm thử: các biện pháp của các kiểm thử viên và nỗ lực của người sử dụng trong việc cố gắng kiểm tra sửa đổi.
• Các biện pháp khác nhau mà bảo trì sử dụng bao gồm: kích thước của phần mềm, độ phức tạp, tính dễ hiểu và khả năng bảo trì.

Cung cấp các nỗ lực bảo trì phần mềm, bởi chủng loại, cho các loại ứng dụng khác nhau cung cấp thông tin kinh doanh cho người dùng và các tổ chức của họ. Nó cũng cho phép so sánh các hồ sơ bảo trì phần mềm nội bộ trong một cơ quan, tổ chức.

3. Quy trình bảo trì phần mềm

Ngoài các quy trình công nghệ phần mềm tiêu chuẩn và hoạt động được mô tả trong IEEE 14.764, có một số hoạt động mà là duy nhất để bảo trì.

3.1. Các bước trong bảo trì phần mềm

Quy trình bảo trì cung cấp các hoạt động cần thiết và chi tiết đầu vào / đầu ra cho những hoạt động như mô tả trong IEEE 14764. Các hoạt động quy trình bảo trì của IEEE 14.764 được thể hiện trong hình 5.2. Các hoạt động bảo trì phần mềm bao gồm:

• Việc thực hiện quy trình,
• Vấn đề và phân tích sửa đổi,
• Thực hiện sửa đổi,
• Xem xét bảo trì / nghiệm thu,
• Tiến hóa phần mềm
• Nghỉ hưu phần mềm

Gần đây, phương pháp nhanh nhẹn, nhằm thúc đẩy quá trình ánh sáng, đã được cũng thích nghi với bảo trì. Yêu cầu này xuất phát từ nhu cầu ngày càng tăng cho quay vòng nhanh các dịch vụ bảo trì. Cải tiến quy trình bảo trì phần mềm được hỗ trợ bởi các mô hình trưởng thành năng lực bảo trì phần mềm chuyên dụng

3.2. Các hoạt động trong bảo trì, bảo dưỡng phần mềm

Quá trình bảo dưỡng gồm các hoạt động và nhiệm vụ cần thiết để sửa đổi một sản phẩm phần mềm hiện có trong khi vẫn giữ toàn vẹn của nó. Những hoạt động và nhiệm vụ là trách nhiệm của các nhà bảo trì. Như đã lưu ý, nhiều hoạt động bảo dưỡng tương tự như phát triển phần mềm. Bảo trì thực hiện phân tích, thiết kế, mã hóa, thử nghiệm, và tài liệu. Họ phải theo dõi các yêu cầu trong hoạt động của họ, giống như được thực hiện trong tài liệu hướng dẫn phát triển và cập nhật là đường cơ sở thay đổi. IEEE 14.764 khuyến cáo rằng khi một nhà bảo trì sử dụng một quá trình phát triển, nó phải được thay đổi để đáp ứng các nhu cầu cụ thể. Tuy nhiên, để bảo trì phần mềm, một số hoạt động liên quan đến quy trình độc đáo để bảo trì phần mềm.

3.2.1. Các hoạt động độc lập

Có một số quy trình, hoạt động, và thực hành là duy nhất để bảo trì phần mềm:

• Hiểu biết chương trình: các hoạt động cần thiết để có được một kiến thức tổng quát về những gì một sản phẩm phần mềm nào và làm thế nào các bộ phận làm việc cùng nhau.
• Chuyển tiếp: một chuỗi kiểm soát và điều phối các hoạt động trong đó phần mềm được chuyển dần từ các nhà phát triển cho nhà bảo trì.
• Sửa đổi yêu cầu chấp nhận / từ chối: sửa đổi yêu cầu công việc vượt quá một kích thước nhất định / nỗ lực / phức tạp có thể bị từ chối bởi người duy trì và định tuyến lại đến một nhà phát triển.
• Bảo trì giúp đỡ phối hợp: một người dùng cuối và bảo trì phối hợp hỗ trợ chức năng mà gây ra sự đánh giá, ưu tiên, và chi phí của các yêu cầu sửa đổi.
• Phân tích tác động: một kỹ thuật để xác định khu vực bị ảnh hưởng bởi sự thay đổi tiềm năng;
• Hiệp định mức độ bảo trì dịch vụ và giấy phép bảo dưỡng và các hợp đồng: thỏa thuận hợp đồng mô tả các dịch vụ và mục tiêu chất lượng.

3.2.2. Hoạt động hỗ trợ

Bảo trì cũng có thể thực hiện các hoạt động hỗ trợ, chẳng hạn như tài liệu hướng dẫn, quản lý cấu hình phần mềm, xác minh và xác nhận, giải quyết vấn đề, phần mềm đảm bảo chất lượng, đánh giá và kiểm toán. Một hoạt động hỗ trợ quan trọng bao gồm đào tạo các nhà bảo trì và người sử dụng.

3.2.3. Các hoạt động lập kế hoạch bảo trì phần mềm

Một hoạt động quan trọng để bảo trì phần mềm đang có kế hoạch, và bảo trì phải giải quyết các vấn đề liên quan đến một số quan điểm quy hoạch, bao gồm cả:

• Lập kế hoạch kinh doanh (cấp độ tổ chức),
• Lập kế hoạch bảo dưỡng (cấp độ chuyển tiếp),
• Lập kế hoạch phát hành / phiên bản (cấp độ phần mềm)
• Lập kế hoạch yêu cầu thay đổi phần mềm cá nhân (cấp độ yêu cầu) Ở cấp độ yêu cầu cá nhân, kế hoạch được thực hiện trong quá trình phân tích tác động (xem phần 2.1.3, Phân tích tác động). Các hoạt động lập kế hoạch phát hành / phiên bản yêu cầu các nhà bảo trì:
• Thu thập các ngày khả dụng của các yêu cầu cá nhân,
• Đồng ý với người dùng trên các nội dung của bản phát hành/ phiên bản kế tiếp,
• Xác định các xung đột tiềm năng và phát triển các giải pháp thay thế,
• Đánh giá nguy cơ của một thông cáo được đưa ra và phát triển một kế hoạch dự phòng trong trường hợp các vấn đề sẽ phát sinh,
• Thông báo cho tất cả các bên liên quan

Trong khi các dự án phát triển phần mềm thường có thể kéo dài từ vài tháng đến vài năm, giai đoạn bảo trì thường kéo dài trong nhiều năm. Lập dự toán các nguồn lực là một yếu tố quan trọng của việc lập kế hoạch bảo trì. Lập kế hoạch bảo trì phần mềm nên bắt đầu với quyết định để phát triển một sản phẩm phần mềm mới và nên xem xét các mục tiêu chất lượng. Một tài liệu khái niệm cần được phát triển, theo sau là một kế hoạch bảo trì. Khái niệm bảo trì cho mỗi sản phẩm phần mềm cần phải được ghi trong kế hoạch và cần giải quyết

• Phạm vi của bảo trì phần mềm
• Thích ứng của quá trình bảo trì phần mềm
• Xác định các tổ chức bảo trì phần mềm
• Ước tính chi phí bảo trì phần mềm.

Bước tiếp theo là phát triển một kế hoạch bảo trì phần mềm tương ứng. Kế hoạch này cần được chuẩn bị trong thời gian phát triển phần mềm và nên xác định cách người dùng sẽ yêu cầu sửa đổi phần mềm hoặc báo cáo các vấn đề. Lập kế hoạch bảo trì phần mềm được đề cập trong IEEE 14764. Nó cung cấp hướng dẫn cho một kế hoạch bảo trì. Cuối cùng, ở cấp cao nhất, các tổ chức bảo trì sẽ phải tiến hành các hoạt động lập kế hoạch kinh doanh (ngân sách, và nguồn nhân lực tài chính) giống như tất cả các bộ phận khác của tổ chức. Quản lý được thảo luận trong các chương nguyên tắc liên quan của công nghệ phần mềm.

3.2.4. Quản lý cấu hình phần mềm

IEEE 14.764 mô tả quản lý cấu hình phần mềm như là một yếu tố quan trọng của quá trình bảo trì. Các thủ tục quản lý cấu hình phần mềm sẽ cung cấp cho việc xác minh, xác nhận, và kiểm toán của mỗi bước cần thiết để xác định, ủy quyền, thực hiện và phát hành các sản phẩm phần mềm. Nó không phải là chỉ đơn giản là đủ để theo dõi các yêu cầu sửa đổi hoặc vấn đề báo cáo. Các sản phẩm phần mềm và bất kỳ thay đổi được thực hiện cho nó phải được kiểm soát. Điều khiển này được thiết lập bằng cách thực hiện và thực thi một quá trình quản lý cấu hình phần mềm đã được phê duyệt (SCM). Quản lý cấu hình phần mềm KA cung cấp thông tin chi tiết của SCM và thảo luận về quá trình mà các yêu cầu thay đổi phần mềm trình, đánh giá và phê duyệt. SCM để bảo trì phần mềm là khác nhau từ SCM cho phát triển phần mềm trong số thay đổi nhỏ mà phải được kiểm soát trên phần mềm hoạt động. Quá trình SCM được thực hiện bằng cách phát triển và theo một kế hoạch quản lý cấu hình phần mềm và quy trình hoạt động. Bảo trì tham gia Ban kiểm soát cấu hình để xác định nội dung của việc phát hành / phiên bản tiếp theo.

3.2.5. Chất lượng phần mềm

Nó không phải là chỉ đơn giản là đủ để hy vọng rằng việc gia tăng chất lượng sẽ cho kết quả từ việc bảo trì phần mềm. Bảo trì cần phải có một chương trình chất lượng phần mềm. Nó phải được quy hoạch và quy trình phải được thực hiện để hỗ trợ quá trình bảo trì. Các hoạt động và kỹ thuật để đảm bảo chất lượng phần mềm (SQA), V & V, đánh giá, và kiểm toán phải được lựa chọn trong sự phối hợp với tất cả các quá trình khác để đạt được mức mong muốn về chất lượng. Nó cũng khuyến cáo rằng các nhà bảo trì thích ứng với quá trình phát triển phần mềm, kỹ thuật và phân phôi (ví dụ, tài liệu thử nghiệm), và kết quả xét nghiệm. Thông tin chi tiết có thể được tìm thấy trong các phần mềm chất lượng KA.

4. Các kĩ thuật trong bảo trì phần mềm

Chủ đề này giới thiệu một số kỹ thuật thường được chấp nhận sử dụng trong bảo trì phần mềm.

4.1. Đọc hiểu chương trình

Các lập trình viên dành nhiều thời gian đọc sách và các chương trình sự hiểu biết đáng kể để thực hiện thay đổi. Trình duyệt mã là công cụ quan trọng cho chương trình hiểu và được sử dụng để tổ chức và mã nguồn hiện nay. Tài liệu rõ ràng và súc tích cũng có thể hỗ trợ trong chương trình hiểu.

4.2. Tái cấu trúc

Tái cấu trúc được định nghĩa là việc kiểm tra và thay đổi phần mềm để pha nó trong một hình thức mới, và bao gồm việc thực hiện tiếp theo của hình thức mới. Nó thường không được thực hiện để cải thiện khả năng bảo trì nhưng để thay thế lão hóa phần mềm kế thừa. Tái cấu trúc là một kỹ thuật tái cấu trúc đó nhằm tổ chức lại một chương trình mà không cần thay đổi hành vi của nó. Nó tìm cách cải thiện cấu trúc chương trình và bảo trì của nó. Kỹ thuật refactoring có thể được sử dụng trong quá trình thay đổi nhỏ.

4.3. Kĩ thuật đảo ngược

Kỹ thuật đảo ngược là quá trình phân tích phần mềm để xác định thành phần của phần mềm và liên mối quan hệ của họ và tạo ra các cơ quan đại diện của các phần mềm dưới hình thức khác hoặc ở mức độ trừu tượng cao hơn. Kỹ thuật đảo ngược là thụ động; nó không thay đổi phần mềm hoặc kết quả trong phần mềm mới. Nỗ lực đảo ngược kỹ thuật sản xuất đồ thị cuộc gọi và đồ thị luồng điều khiển từ mã nguồn. Một loại kỹ thuật đảo ngược là tài liệu hóa lại. Một loại khác là phục hồi thiết kế. Cuối cùng, dữ liệu kỹ thuật đảo ngược, nơi schemas logic được thu hồi từ cơ sở dữ liệu vật lý, đã trở nên quan trọng trong vài năm qua. Công cụ là chìa khóa cho kỹ thuật và nhiệm vụ liên quan ngược như tài liệu hóa lại và phục hồi thiết kế.

4.4. Chuyển đổi và tích hợp

Trong suốt cuộc đời của phần mềm, nó có thể phải được sửa đổi để chạy trong môi trường khác nhau. Để di chuyển nó đến một môi trường mới, các nhà bảo trì cần phải xác định các hành động cần thiết để thực hiện việc chuyển đổi, và sau đó phát triển và tài liệu hóa các bước cần thiết để thực hiện việc di chuyển trong một kế hoạch di cư bao gồm các yêu cầu chuyển đổi, công cụ chuyển đổi, chuyển đổi của sản phẩm và dữ liệu, thực hiện, xác minh, và hỗ trợ. Phần mềm di cư cũng có thể kéo theo một số hoạt động khác như:

• Thông báo về mục định: một tuyên bố về lý do tại sao môi trường cũ không còn được hỗ trợ, theo sau là một mô tả của môi trường mới và ngày sẵn có.
• Các hoạt động song song: làm cho có sẵn các môi trường cũ và mới để người dùng trải nghiệm một chuyển đổi suôn sẻ với môi trường mới.
• Thông báo hoàn thành: khi di chuyển dự kiến được hoàn tất, một thông báo được gửi đến tất cả có liên quan.
• Xem xét sau phẫu thuật: đánh giá về hoạt động song song và tác động của thay đổi môi trường mới.
• Dữ liệu lưu trữ: lưu trữ các dữ liệu phần mềm cũ.

4.5. Nghỉ hưu phần mềm

Một khi phần mềm đã đạt đến kết thúc của cuộc sống hữu ích của nó, nó phải được nghỉ hưu. Một phân tích nên được thực hiện để hỗ trợ trong việc đưa ra các quyết định nghỉ hưu. Phân tích này nên được bao gồm trong kế hoạch nghỉ hưu, trong đó bao gồm các yêu cầu về hưu, tác động, thay thế, lịch trình, và nỗ lực. Tiếp cận của các kho lưu trữ các bản sao của dữ liệu cũng có thể được bao gồm. Nghỉ hưu phần mềm đòi hỏi một số hoạt động tương tự như di cư.

5. Công cụ sử dụng trong bảo trì phần mềm

Chủ đề này bao gồm các công cụ đặc biệt quan trọng trong việc bảo trì phần mềm, nơi phần mềm hiện đang được sửa đổi. Các ví dụ về chương trình hiểu bao gồm:

• Cắt chương trình, mà chỉ chọn các phần của một chương trình bị ảnh hưởng bởi sự thay đổi;
• Phân tích tĩnh, cho phép xem chung và bản tóm tắt của một nội dung chương trình;
• Phân tích động, cho phép các nhà bảo trì để theo dõi con đường thực hiện của một chương trình;
• Phân tích lưu lượng dữ liệu, cho phép các nhà bảo trì để theo dõi tất cả các luồng dữ liệu có thể có của một chương trình;
• Tham chiếu xuyên qua, tạo ra các chỉ số thành phần của chương trình;
• Phân tích phụ thuộc, giúp bảo trì phân tích và hiểu được mối quan hệ giữa các thành phần của một chương trình.

Các công cụ kỹ thuật đảo ngược hỗ trợ quá trình này bằng cách làm ngược từ một sản phẩm hiện có để tạo ra các đồ tạo tác như đặc điểm kỹ thuật và thiết kế giới thiệu, sau đó có thể được biến đổi để tạo ra một sản phẩm mới từ một tuổi. Bảo trì cũng sử dụng phần mềm kiểm tra, quản lý cấu hình phần mềm, tài liệu phần mềm, và các công cụ đo lường phần mềm.

Nguồn: Internet