Trường Đại Học Công Nghiệp Hà NộiKhoa công nghệ thông tinMục lụcLời Nói Đầu1Danh mục các thuật ngữ, ký hiệu và các chữ viết tắt2Chương 1. Tích hợp các hoạt động chất lượng trong vòng đời dự án31.1.Phương pháp phát triển phần mềm truyền thống và các phương pháp khác31.1.1.Mô hình thác nước31.1.2.Mô hình Agile51.1.3.So sánh mô hình thác nước và mô hình Agile91.2.Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm111.3.Xác minh, thẩm định và đánh giá chất lượng12Chương 2. Rà soát142.1. Định nghĩa về rà soát của IEEE142.2. Mục tiêu rà soát142.3. Những rà soát thiết kế hình thức152.4. Các rà soát ngang hàng (peer review)172.5 Các ý kiến chuyên gia20Chương 3. Đảm bảo chất lượng của các thành phần bảo trì phần mềm243.1. Giới thiệu243.2. Cơ sở cho chất lượng bảo trì phần mềm cao243.2.1. Cơ sở 1: Chất lượng gói phần mềm243.2.2. Cơ sở 2: Chính sách bảo trì263.3. Các thành phần chất lượng phần mềm tiền bảo trì273.3.1. Xem xét lại hợp đồng bảo trì273.3.2. Lập kế hoạch bảo trì283.4. Các công cụ đảm bảo chất lượng phần mềm313.4.1. Công cụ SQA cho bảo trì sửa lỗi313.4.2. Công cụ SQA cho bảo trì cải thiện chức năng323.4.3. Công cụ SQA cơ sở cho bảo trì phần mềm323.4.4. Công cụ SQA cho giám sát quản lý bảo trì phầm mềm36Chương 4. CASE Tool và ảnh hưởng của nó lên chất lượng phần mềm404.1. Khái niệm CASE Tool404.2. Đóng góp của Case Tool cho chất lượng phần mềm424.3. Đóng góp của Case Tool cho chất lượng bảo trì phần mềm454.4. Đóng góp của Case Tool cho quản lý dự án46Chương 5. Đảm bảo chất lượng phần mềm của các yếu tố bên ngoài cùng tham gia475.1. Những thành phần bên ngoài đóng góp vào dự án phần mềm475.2 Rủi ro và lợi ích của giới thiệu người tham dự ngoài485.3. Những mục tiêu đảm bảo chất lượng về sự đóng góp người tham gia bên ngoài505.4. Các công cụ đảm bảo chất lượng những đóng góp của các thành viên đóng góp bên ngoài.51Tài liệu tham khảo53 Lời Nói ĐầuTrong môi trường kinh doanh ngày nay, nếu muốn giữ vững tỷ lệ chiếm lĩnh thị trường chưa nói gì đến việc tăng tỷ lệ đó cần thiết phải xây dựng được hệ thống đảm bảo chất lượng các phần mềm trong doanh nghiệp đạt tiêu chuẩn nhất định.Ngày nay, các khách hàng xem trọng chất lượng sản phẩm hơn là sự tin tưởng đối với các doanh nghiệp trong nước, và trong mọi trường hợp giá cả chưa hẳn đã là nhân tố quyết định trong sự lựa chọn của khách hàng. Chất lượng đã thay thế giá cả, và điều đó đúng với cả công nghiệp, công nghệ, dịch vụ và nhiều thị trường khác. Đặc biệt trong thị trường công nghệ hiện nay, các phần mềm càng được quan tâm nhiều hơn về việc chất lượng có đảm bảo hay không ? Có thể nói chất lượng sản phẩm đóng vai trò quan trọng quyết định sự sống còn của các doanh nghiệp phần mềm hiện nay.Dưới đây là các lý do tại sao chất lượng phần mềm quan trọng và ảnh hưởng to lớn đến các doanh nghiệp phần mềm, vì: •Đáp ứng kỳ vọng của khách hàng•Tăng uy tín, danh tiếng và hình ảnh cho doanh nghiệp•Đáp ứng hoặc vượt trên các tiêu chuẩn ngành•Quản lý chi phí hiệu quảTrong bài báo cáo này, chúng ta cùng tìm hiểu các thành phần ảnh hưởng đến việc đảm bảo chất lượng phần mềm trong vòng đời dự án phần mềm. Danh mục các thuật ngữ, ký hiệu và các chữ viết tắtTừ viết tắtViết đầy đủChức năng Ý nghĩaQAQuality AssuranceNgười chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc giữa các bên liên quan.EREntity RelationshipMô tả các đối tượng trong thế giới thực bằng các thực thể, quan hệ.FailureLỗi phần mềmCOTS softwarePhần mềm bán sẵnDRDesign ReviewRà soát thiết kếSQASoftware Quality AssuranceBộ phận giám sát và quản lý chất lượng Chương 1. Tích hợp các hoạt động chất lượng trong vòng đời dự ánMục lụcLời Nói Đầu1Danh mục các thuật ngữ, ký hiệu và các chữ viết tắt2Chương 1. Tích hợp các hoạt động chất lượng trong vòng đời dự án31.1.Phương pháp phát triển phần mềm truyền thống và các phương pháp khác31.1.1.Mô hình thác nước31.1.2.Mô hình Agile51.1.3.So sánh mô hình thác nước và mô hình Agile91.2.Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm111.3.Xác minh, thẩm định và đánh giá chất lượng12Chương 2. Rà soát142.1. Định nghĩa về rà soát của IEEE142.2. Mục tiêu rà soát142.3. Những rà soát thiết kế hình thức152.4. Các rà soát ngang hàng (peer review)172.5 Các ý kiến chuyên gia20Chương 3. Đảm bảo chất lượng của các thành phần bảo trì phần mềm243.1. Giới thiệu243.2. Cơ sở cho chất lượng bảo trì phần mềm cao243.2.1. Cơ sở 1: Chất lượng gói phần mềm243.2.2. Cơ sở 2: Chính sách bảo trì263.3. Các thành phần chất lượng phần mềm tiền bảo trì273.3.1. Xem xét lại hợp đồng bảo trì273.3.2. Lập kế hoạch bảo trì283.4. Các công cụ đảm bảo chất lượng phần mềm313.4.1. Công cụ SQA cho bảo trì sửa lỗi313.4.2. Công cụ SQA cho bảo trì cải thiện chức năng323.4.3. Công cụ SQA cơ sở cho bảo trì phần mềm323.4.4. Công cụ SQA cho giám sát quản lý bảo trì phầm mềm36Chương 4. CASE Tool và ảnh hưởng của nó lên chất lượng phần mềm404.1. Khái niệm CASE Tool404.2. Đóng góp của Case Tool cho chất lượng phần mềm424.3. Đóng góp của Case Tool cho chất lượng bảo trì phần mềm454.4. Đóng góp của Case Tool cho quản lý dự án46Chương 5. Đảm bảo chất lượng phần mềm của các yếu tố bên ngoài cùng tham gia475.1. Những thành phần bên ngoài đóng góp vào dự án phần mềm475.2 Rủi ro và lợi ích của giới thiệu người tham dự ngoài485.3. Những mục tiêu đảm bảo chất lượng về sự đóng góp người tham gia bên ngoài505.4. Các công cụ đảm bảo chất lượng những đóng góp của các thành viên đóng góp bên ngoài.51Tài liệu tham khảo53 Lời Nói ĐầuTrong môi trường kinh doanh ngày nay, nếu muốn giữ vững tỷ lệ chiếm lĩnh thị trường chưa nói gì đến việc tăng tỷ lệ đó cần thiết phải xây dựng được hệ thống đảm bảo chất lượng các phần mềm trong doanh nghiệp đạt tiêu chuẩn nhất định.Ngày nay, các khách hàng xem trọng chất lượng sản phẩm hơn là sự tin tưởng đối với các doanh nghiệp trong nước, và trong mọi trường hợp giá cả chưa hẳn đã là nhân tố quyết định trong sự lựa chọn của khách hàng. Chất lượng đã thay thế giá cả, và điều đó đúng với cả công nghiệp, công nghệ, dịch vụ và nhiều thị trường khác. Đặc biệt trong thị trường công nghệ hiện nay, các phần mềm càng được quan tâm nhiều hơn về việc chất lượng có đảm bảo hay không ? Có thể nói chất lượng sản phẩm đóng vai trò quan trọng quyết định sự sống còn của các doanh nghiệp phần mềm hiện nay.Dưới đây là các lý do tại sao chất lượng phần mềm quan trọng và ảnh hưởng to lớn đến các doanh nghiệp phần mềm, vì: •Đáp ứng kỳ vọng của khách hàng•Tăng uy tín, danh tiếng và hình ảnh cho doanh nghiệp•Đáp ứng hoặc vượt trên các tiêu chuẩn ngành•Quản lý chi phí hiệu quảTrong bài báo cáo này, chúng ta cùng tìm hiểu các thành phần ảnh hưởng đến việc đảm bảo chất lượng phần mềm trong vòng đời dự án phần mềm. Danh mục các thuật ngữ, ký hiệu và các chữ viết tắtTừ viết tắtViết đầy đủChức năng Ý nghĩaQAQuality AssuranceNgười chịu trách nhiệm đảm bảo chất lượng sản phẩm thông qua việc đưa ra quy trình làm việc giữa các bên liên quan.EREntity RelationshipMô tả các đối tượng trong thế giới thực bằng các thực thể, quan hệ.FailureLỗi phần mềmCOTS softwarePhần mềm bán sẵnDRDesign ReviewRà soát thiết kếSQASoftware Quality AssuranceBộ phận giám sát và quản lý chất lượng Chương 1. Tích hợp các hoạt động chất lượng trong vòng đời dự ánBÁO CÁO THỰC NGHIỆMHỌC PHẦN ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀMĐề tài: Phân tích các thành phần đảm bảo chất lượng phần mềm cho dự án X
Tích hợp các hoạt động chất lượng trong vòng đời dự án
Phương pháp phát triển phần mềm truyền thống và các phương pháp khác
Có nhiều mô hình phát triển phần mềm truyền thống, trong đó mô hình thác nước (Waterfall model) là nổi tiếng và phổ biến nhất Các mô hình khác bao gồm mô hình chữ V (V model) và mô hình xoắn ốc (Spiral model).
Mô hình thác nước có vòng đời phát triển phần mềm bao gồm các giai đoạn sau:
Các hoạt động liên quan đến các giai đoạn khác nhau như sau:
Phân tích yêu cầu là bước đầu tiên trong các dự án áp dụng mô hình thác nước, nhằm xác định và phân tích toàn bộ nhu cầu kinh doanh, yêu cầu từ người dùng đối với sản phẩm, cũng như các ràng buộc và rủi ro liên quan.
Thiết kế hệ thống là bước quan trọng trong quy trình phát triển sản phẩm, nơi nhóm dự án xây dựng thiết kế đáp ứng các yêu cầu đã xác định Quá trình này bao gồm thiết kế phần cứng, phần mềm, lựa chọn ngôn ngữ lập trình và phương pháp lưu trữ dữ liệu Thiết kế hệ thống không chỉ giúp đảm bảo sản phẩm phù hợp với nhu cầu người dùng mà còn xác định giá trị sử dụng của dự án Nếu gặp phải vấn đề trong bước này, có thể cần quay lại bước đầu tiên để điều chỉnh yêu cầu.
Giai đoạn thực hiện bắt đầu khi hệ thống đã được thiết kế hoàn chỉnh, trong đó các nhóm chức năng sản phẩm sẽ được triển khai để đáp ứng các tiêu chuẩn đã xác định trước đó Đây là thời điểm các nhiệm vụ công việc đã thảo luận ở bước 2 được thực hiện, với đội ngũ lập trình đóng vai trò chủ chốt trong việc triển khai hệ thống.
Giai đoạn kiểm thử (Testing) là trách nhiệm của đội ngũ QA và tester, nhằm phát hiện và báo cáo các lỗi trong hệ thống Công việc này bao gồm cả kiểm thử tính năng và phi tính năng Đây là một giai đoạn cực kỳ quan trọng, đòi hỏi sự chính xác cao để đảm bảo hệ thống được kiểm tra đầy đủ, đáp ứng các mục tiêu thiết kế và chức năng người dùng, cũng như giải quyết các nhu cầu kinh doanh.
Giai đoạn phát triển hệ thống, hay còn gọi là triển khai sản phẩm, là thời điểm sản phẩm chính thức được đưa vào môi trường sử dụng thực tế Trong giai đoạn này, nhóm dự án cần đảm bảo rằng môi trường hoạt động ổn định, không có lỗi trên server, và tất cả các tiêu chí kiểm tra đã được đáp ứng Việc kiểm tra lại môi trường sau khi ứng dụng được triển khai là cần thiết để đảm bảo sản phẩm hoạt động trơn tru và không gặp phải vấn đề nào.
Bảo trì hệ thống là giai đoạn cuối cùng trong quy trình dự án, nơi nhóm dự án tập trung vào việc giải quyết các vấn đề của khách hàng Trong lĩnh vực phần mềm, đây thường là thời điểm phát hành các bản cập nhật và sửa lỗi nhằm cải thiện hiệu suất và tính ổn định của sản phẩm.
Mô hình thác nước trong phát triển phần mềm hoạt động theo quy trình tuần tự, không cho phép thay đổi khi có yêu cầu mới từ khách hàng Điều này có thể dẫn đến sự không hài lòng từ phía khách hàng, làm cho yêu cầu bị chờ xử lý, gây ra thiệt hại về lợi nhuận và lãng phí thời gian.
Các phương pháp phát triển phần mềm truyền thống đang bộc lộ nhiều nhược điểm, dẫn đến tỷ lệ thất bại cao trong các dự án công nghệ Để khắc phục vấn đề này, nhiều cá nhân và công ty đã phát triển các phương pháp hiện đại và linh hoạt hơn nhằm thích ứng với yêu cầu của thời đại mới.
Agile là một phương pháp phát triển phần mềm hiện đại, bao gồm nhiều phương pháp khác nhau, nhằm khắc phục những hạn chế của các phương pháp truyền thống Phương pháp này ưu tiên sự tham gia của khách hàng từ sớm trong chu kỳ phát triển, khuyến khích kiểm tra thường xuyên và liên tục từ phía khách hàng Kiểm tra được thực hiện tại mỗi phiên bản ổn định, bắt đầu từ giai đoạn đầu của dự án và kéo dài đến khi hoàn thành Hai biến thể phổ biến của Agile là Scrum và Extreme.
Khái niệm Agile đề cập đến phương pháp phát triển phần mềm linh hoạt, tập trung vào việc tối ưu hóa quy trình phát triển nhằm nhanh chóng đưa sản phẩm đến tay người dùng.
4 tuyên ngôn cần tuân thủ trong phương pháp Agile
Cá nhân và sự tương hỗ giữa các thành viên trong nhóm đóng vai trò quan trọng hơn so với quy trình và công cụ Khi tập trung vào con người và xây dựng mối quan hệ hỗ trợ lẫn nhau, những thành viên có năng lực sẽ cùng nhau hợp tác, từ đó góp phần tạo nên thành công cho dự án.
Phần mềm dùng được tốt hơn tài liệu đầy đủ: Tập trung thời gian để làm ra phần mềm hoàn chỉnh đáp ứng hoàn hảo yêu cầu khách hàng.
Cộng tác với khách hàng là yếu tố quan trọng hơn việc chỉ đàm phán hợp đồng Việc hiểu rõ nhu cầu của khách hàng giúp chúng ta tư vấn hiệu quả và điều chỉnh sản phẩm phù hợp, thay vì chỉ dựa vào các điều khoản có trong hợp đồng.
Agile khuyến khích việc phản hồi và thích nghi với sự thay đổi thay vì chỉ bám sát kế hoạch ban đầu Điều này có thể bao gồm những thay đổi về công nghệ, nhân sự, hoặc thời hạn dự án Sự linh hoạt này giúp đội ngũ phát triển nhanh chóng điều chỉnh để đáp ứng nhu cầu thực tế và tối ưu hóa quy trình làm việc.
12 nguyên tắc quan trọng của Agile
Đáp ứng toàn diện nhu cầu khách hàng thông qua việc giao hàng sớm và sản phẩm có giá trị.
Thay đổi yêu cầu được chào đón, thậm chí là rất muộn trong quá trình phát triển.
Giao phần mềm chạy được cho khách hàng một cách thường xuyên.
Nhà kinh doanh và các kỹ sư phần mềm cần làm việc cùng nhau trong suốt dự án.
Xây dựng dự án cần tập trung vào những cá nhân có động lực, đồng thời cung cấp sự hỗ trợ cần thiết và tạo ra một môi trường làm việc tích cực Điều này sẽ giúp tăng cường niềm tin và khuyến khích họ hoàn thành công việc một cách hiệu quả.
Trao đổi trực tiếp là cách truyền đạt thông tin hiệu quả nhất.
Thước đo chính của tiến độ là phần mềm chạy tốt.
Phát triển liên tục và bền vững.
Cải tiến sự linh hoạt bằng cách quan tâm đến kỹ thuật và thiết kế.
Nghệ thuật tối đa hóa lượng công việc chưa xong - Sự đơn giản là cần thiết.
Thích ứng thường xuyên với những thay đổi. Đặc trưng của Agile
Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm
Các hoạt động đảm bảo chất lượng là yếu tố quan trọng trong quy trình dự án, liên quan đến việc hoàn thành các giai đoạn và mốc quan trọng Những hoạt động này cần được tích hợp vào kế hoạch phát triển dự án Để đảm bảo chất lượng hiệu quả, những người lập kế hoạch cần xác định rõ các tiêu chí và phương pháp thực hiện.
Khi lập kế hoạch đảm bảo chất lượng cho dự án, việc xác định danh sách các hoạt động cần thiết là rất quan trọng Mỗi hoạt động cần được phân tích kỹ lưỡng để xác định các yêu cầu và tiêu chí cụ thể nhằm đảm bảo chất lượng tối ưu cho dự án.
Loại hoạt động đảm bảo chất lượng áp dụng.
Người thực hiện hoạt động và tài nguyên yêu cầu.
Tài nguyên yêu cầu cho việc khắc phục sai sót và thay đổi.
Hình 1.2 Tiến trình quản lý chất lượng phần mềm
Các yếu tố ảnh hưởng tới hoạt động đảm bảo chất lượng phần mềm:
Yếu tố dự án bao gồm độ lớn của dự án, sự phức tạp và độ khó của kỹ thuật, phạm vi của các thành phần sử dụng lại, cũng như hậu quả nếu dự án gặp lỗi Những yếu tố này đóng vai trò quan trọng trong việc đánh giá và quản lý hiệu quả dự án.
Yếu tố nhóm đóng vai trò quan trọng trong thành công của dự án, bao gồm trình độ chuyên môn của các thành viên, sự quen thuộc và kinh nghiệm của nhóm với lĩnh vực liên quan Ngoài ra, tính sẵn sàng của các thành viên hỗ trợ cũng ảnh hưởng đến hiệu quả làm việc Cuối cùng, sự hiểu biết lẫn nhau giữa các thành viên, đặc biệt là số lượng thành viên mới trong nhóm, cũng cần được xem xét để đảm bảo sự phối hợp tốt.
Xác minh, thẩm định và đánh giá chất lượng
Ba khía cạnh đảm bảo chất lượng của sản phẩm phần mềm được sát hạch dưới dạng:
Xác minh là quá trình đánh giá các sản phẩm làm việc trung gian trong vòng đời phát triển phần mềm, nhằm kiểm tra xem liệu nhà phát triển có đang đi đúng hướng để tạo ra sản phẩm cuối cùng hay không.
Các sản phẩm trung gian trong quá trình phát triển phần mềm bao gồm các tài liệu quan trọng như đặc tả yêu cầu, tài liệu thiết kế, thiết kế cơ sở dữ liệu, sơ đồ ER và các test case Những tài liệu này đóng vai trò quan trọng trong việc đảm bảo sự thống nhất và hiệu quả trong từng giai đoạn phát triển.
• Xác minh kiểm tra xem sản phẩm có được xây dựng đúng theo yêu cầu và đặc điểm kỹ thuật thiết kế không.
• Thực hiện mà không cần chạy phần mềm
Thẩm định là quá trình đánh giá một hệ thống hoặc thành phần trong suốt hoặc sau khi hoàn thành quá trình phát triển, nhằm xác định xem sản phẩm có đáp ứng đúng các yêu cầu cụ thể đã được đặt ra từ đầu hay không.
• Thẩm định xác định xem phần mềm có phù hợp với nhu cầu sử dụng và đáp ứng nhu cầu nghiệp vụ không.
Quá trình Đánh giá chất lượng (Qualification) được thực hiện song song với việc chạy phần mềm, nhằm xác định xem một hệ thống hoặc một thành phần có phù hợp với mục đích sử dụng hay không.
• Đánh giá chất lượng tập trung vào những khía cạnh hoạt động, ở đó việc bảo trì là vấn đề chính
Một thành phần phần mềm được phát triển và tài liệu hóa theo các chuẩn mực, kiểu dáng và cấu trúc chuyên nghiệp sẽ dễ dàng bảo trì hơn so với những thành phần có mã nguồn không rõ ràng.
Rà soát
Định nghĩa về rà soát của IEEE
Định nghĩa của IEEE(1990), quá trình rà soát là:
Quá trình này bao gồm việc trình bày sản phẩm công việc hoặc tập hợp các sản phẩm công việc trước toàn bộ cá nhân tham gia dự án, bao gồm giám đốc, người dùng, khách hàng và các bên liên quan Mục tiêu là thu thập ý kiến phản hồi và sự phê chuẩn từ những người có liên quan đến dự án.
Một số phương pháp dùng để xem xét lại tài liệu:
- Xem xét lại thiết kế hình thức (Formal design reviews)
- Xem xét lại ngang hàng (Peer reviews)
Mục tiêu rà soát
Mục đích được chia làm 2 loại: mục đích trực tiếp và gián tiếp.
Phát hiện lỗi phân tích và thiết kế.
Xác định các rủi ro mới.
Xác định sự sai lệch so với mẫu, các kiểu thủ tục và qui ước.
Để phê chuẩn sản phẩm của phân tích hoặc thiết kế.
Nơi họp mặt không chính thức để trao đổi về những kiến thức chuyên môn.
Ghi lại những lỗi phân tích và thiết kế sẽ hỗ trợ một cơ sở cho những hoạt động sửa chữa lỗi trong tương lai.
Những rà soát thiết kế hình thức
Rà soát thiết kế hình thức(DRs-formal Design Reviews) là rà soát duy nhất cần thiết cho việc phê duyệt sản phẩm thiết kế.
Rà soát thiết kế hình thức là quá trình cần thiết để đảm bảo sự hoàn thiện của tài liệu phân tích và thiết kế, có thể thực hiện ở bất kỳ giai đoạn phát triển nào.
Một danh sách các review thiết kế chính thức:
DPR – Development Plan Review: Review kế hoạch phát triển
SRSR – Software Requirement Specification Review: Review đặc tả yêu cầu phần mềm
PDR – Preliminary Design Review: Review thiết kế sơ bộ
DBDR- Detailed Design Review: Review thiết kế chi tiết
TPR – Test Plan Review: Review kế hoạch kiểm thử
STPR – Software Test Procedure Review: Review thủ tục kiểm thử phần mềm
VDR- Version Description Review: Review mô tả phiên bản
OMR- Operator Manual Review: Review vận hành thủ công
SMR- Support Manual Review: Review trợ giúp thủ công
TRR- Test Readiness Review: Review sự sẵn sàng kiểm thử
PRR- Product Release Review: Review bản phát hành sản phẩm
IPR-Installation Plan Review: Review kế hoạch cài đặt
Các nhân tố ảnh hưởng tới DRs
Các hoạt động sau DR được đề xuất
Những người tham gia rà soát thiết kế
Gồm có Review leader và review team.
Người đánh giá dự án cần có kiến thức và kinh nghiệm vững vàng trong việc phát triển các loại dự án được xem xét Họ nên có thâm niên tương đương hoặc cao hơn so với trưởng dự án và duy trì mối quan hệ tốt với trưởng dự án cùng đội ngũ thực hiện Ngoài ra, người đánh giá cũng nên giữ một vị trí bên ngoài đội dự án để đảm bảo tính khách quan trong quá trình đánh giá.
Review team: o Phần lớn không thuộc đội dự án o Kích thước từ 3-5 người o Đa dạng về kinh nghiệm và phương pháp
Sự chuẩn bị cho một phiên bản DR Được hoàn thành bởi 3 thành viên: review leader, review team và development team
Chuẩn bị của Review leader
Bổ nhiệm các thành viên nhóm
Lập lịch các phiên review
Phân chia tài liệu thiết kế cho các thành viên của nhóm
Chuẩn bị của Review team
Xem lại tài liệu thiết kế
Chuẩn bị của Development team
Trình diễn ngắn tài liệu thiết kế
Checklist các công việc review
Một cuộc họp phiên DR thông thường gồm có:
Trình diễn ngắn gọn về tài liệu thiết kế
Các bình luận của các thành viên review team
Kiểm tra và xác nhận thảo luận mỗi bình luận
Các quyết định về tài liệu thiết kế để xác định tiến trình dự án Các quyết định có thể có 3 loại :
Các hoạt động hậu review
Review leader thực hiện sau phiên review
Tổng kết các thảo luận review
Quyết định về sự tiếp tục của dự án
Danh sách các hoạt động cần thiết phải làm
Tên thành viên chịu trách nhiệm theo sát việc hiệu chỉnh
Chắc rằng việc hiệu chỉnh được thực hiện đúng đắn
Việc theo dõi cần được ghi lại
Các rà soát ngang hàng (peer review)
Mục đích chính của peer review là xác định lỗi và độ lệch dựa vào các chuẩn Có hai phương pháp peer reviews:
Kiểm tra từng bước (walkthrough).
Walkthrough phát hiện sai sót và ghi chú lên tài liệu Inspection phát hiện sai sót và kết hợp với nỗ lực để cải tiến.
Những người tham gia vào peer reviews
Một đội peer review tối ưu 3-5 người tham gia.
Tất cả những người tham gia nên là những người cùng địa vị của nhà thiết kế hệ thống phần mềm.
Một đội peer review đề cử bao gồm:
• Một người thực thi (author).
• Các chuyên gia đặc biệt (specialized professionals)
Phân công trách nhiệm trong đội (team assignments)
Hai trong số các thành viên sẽ là:
• Một người dẫn chương trình
• Một người viết tài liệu trong cuộc thảo luận.
Chuẩn bị cho phiên peer review
Lãnh đạo cần xác định các đoạn trong tài liệu thiết kế sẽ được xem xét, lựa chọn thành viên trong nhóm, lập lịch cho các phiên review và cung cấp tài liệu cho các thành viên trước khi diễn ra phiên review.
The peer review team has distinct requirements for inspections and walkthroughs; inspections demand meticulous attention to detail, while walkthroughs involve simpler criteria In an inspection, the focus is on reading and listing their annotations, whereas a walkthrough entails reviewing specific sections of the document.
Trong quá trình kiểm tra, người thuyết trình sẽ đọc một đoạn tài liệu và có thể bổ sung thêm thông tin nếu cần thiết Các bên liên quan sẽ đưa ra chú thích hoặc phản hồi đối với những nhận xét có trong tài liệu.
Bài viết bắt đầu với một phần giới thiệu ngắn gọn từ tác giả, cung cấp cái nhìn tổng quan về dự án và các thiết kế sẽ được xem xét Trong quá trình này, người ghi chép sẽ ghi lại vị trí, mô tả, kiểu dáng và các đặc điểm của mỗi lỗi được chấp nhận, bao gồm những sai sót, phần thiếu sót và các yếu tố cần bổ sung.
Quy tắc thời gian: phiên không nên vượt quá 2 giờ, hoặc lập lịch không nhiều hơn 2 ngày.
Tài liệu sau mỗi phiên review:
• Báo cáo những phát hiện trong phiên inspection
• Báo cáo tóm tắt của phiên inspection
Các hoạt động sau peer review (post-peer review activities)
• Nhắc nhở, sửa chữa hiệu quả, làm lại tất cả các lỗi
• Chuyển giao các bản báo cáo inspection tới CAB để phân tích.
Hiệu quả của peer review (the efficency of peer reviews)
Một vài độ đo phổ biến ước lượng hiệu suất của peer review:
• Số giờ trung bình trên một lỗi.
• Mật độ phát hiện thiếu sót (Số thiếu sót trung bình trên một trang tài liệu thiết kế).
• Hiệu năng peer review bên trong.
Peer review coverage: Là tỉ lệ nhỏ của tài liệu và toàn bộ code đã từng trải qua peer review.
Các ý kiến chuyên gia
Ý kiến của chuyên ra rất hữu ích trong những trường hợp sau:
Thiếu sự hiểu biết đầy đủ về lĩnh vực nào đó.
Tạm thời thiếu những người chuyên nghiệp để tham gia vào đội xem xét lại
Các thành viên chuyên nghiệp cao cấp trong tổ chức không thống nhất được với nhau.
Trong các tổ chức nhỏ, số lượng ứng viên phù hợp cho đội ngũ xem xét lại thường không đủ Để hiểu rõ hơn về các đặc điểm của các phương pháp rà soát, có thể tham khảo bảng so sánh giữa ba phương pháp rà soát khác nhau.
Thuộc tính reviews Inspections Walkthroughs
- Xác định rủi ro mới
- Phê chuẩn tài liệu thiết kế
- Xác định sự sai lệch so với tiêu chuẩn
- Hỗ trợ hoạt động sửa chữa
Lãnh đạo việc xem xét lại
Người đứng đầu kỹ nghệ phần mềm hoặc là thành viên cao cấp
Người điều hành chỉ đạo (ngang hàng)
Người tham gia Các thành viên cấp cao và đại diện khách hàng
Sự tham gia của trưởng dự án
Có Có Có, thông thường là khi bắt đầu xem xét lại
Thành viên chuyên gia trong đội
- Người giám sát tiêu chuẩn
Quá trình xem xét lại
Họp tổng quan Không Có Có
Sự chuẩ n bị của nhữn g ngườ i tham gia
Có – chuẩn bị kỹ lưỡng
Có – chuẩn bị kỹ lưỡng
Có – chuẩn bị tóm lược
Phiên xem xét lại Có Có Có
Bám sát việc sửa chữa
Cơ sở hạ tầng Đào tạo chính thức cho người tham gia
Lỗi liên quan đế thu thập dữ liệu
Không yêu cầu hình thức
Không yêu cầu hình thức
Tài liệu hóa việc xem xét lại
Báo cáo xem xét lại thiết kế hình thức
- Báo cáo đánh giá phiên thanh tra
Báo cáo đánh giá phiên walkthrough
- Báo cáo tổng kết phiên thanh tra
Đảm bảo chất lượng của các thành phần bảo trì phần mềm
Giới thiệu
Giai đoạn hoạt động của vòng đời phần mềm thường kéo dài từ 5 đến 10 năm, nhưng có thể lên đến 15 năm hoặc hơn Điều này phụ thuộc vào khả năng duy trì chất lượng của phần mềm, một yếu tố quan trọng quyết định sự thành công và độ bền bỉ của nó Các tiêu chuẩn như ISO 9000 – 3 và các nghiên cứu từ IEEE và Oskarsson & Glass nhấn mạnh tầm quan trọng của bảo trì phần mềm trong việc kéo dài tuổi thọ và sự hài lòng của người dùng.
Mục tiêu hoạt động QA bảo trì phần mềm:
1) Đảm bảo, với mức độ tin cậy được chấp nhận, rằng những hoạt động bảo trì phù hợp với những yêu cầu kỹ thuật chức năng.
2) Đảm bảo, với mực độ tin cậy được chấp nhận, rằng những hoạt động bảo trì phù hợp với những yêu cầu quản lý lập lịch và ngân sách.
3) Những hoạt động khởi đầu và quản lý nhằm cải thiện và tăng hiệu quả cho bảo trì phần mềm và những hoạt động SQA Điều này liên quan đến việc cải thiện cái nhìn toàn cảnh để đạt được những yêu cầu về chức năng và quản lý trong khi giá thành giảm.
Cơ sở cho chất lượng bảo trì phần mềm cao
3.2.1 Cơ sở 1: Chất lượng gói phần mềm
Chất lượng phần mềm phụ thuộc vào sự thành thạo của đội ngũ phát triển và các hoạt động kiểm soát chất lượng phần mềm (SQA) diễn ra trong suốt quá trình phát triển Nếu chất lượng phần mềm kém, sẽ dẫn đến việc bảo trì không hiệu quả hoặc thậm chí không có.
Hai nhân tố thao tác sản phẩm:
Sự chính xác trong hệ thống bao gồm hai yếu tố chính: đầu ra và tài liệu hướng dẫn Đầu ra cần phải hoàn thành đúng yêu cầu, đảm bảo tính đúng đắn và hợp thời Tài liệu hướng dẫn phải có chất lượng cao, bao gồm tính đầy đủ, sự chính xác, kiểu dáng và cấu trúc hợp lý Bên cạnh đó, độ tin cậy của hệ thống được đánh giá qua tần suất thất bại và khả năng phục hồi của nó.
Ba nhân tố quan trọng cần xem xét khi đánh giá sản phẩm bao gồm sự bảo trì, tính linh động và khả năng kiểm tra Sự bảo trì được thực hiện hiệu quả nhất khi tuân theo cấu trúc phần mềm và yêu cầu kỹ thuật trong tài liệu lập trình Tính linh động đạt được thông qua thiết kế và lập kế hoạch hợp lý, cung cấp không gian ứng dụng lớn hơn nhu cầu hiện tại của người dùng Cuối cùng, khả năng kiểm tra đảm bảo rằng các chuẩn đoán hệ thống do người dùng cung cấp và các chuẩn đoán lỗi do trung tâm hỗ trợ hoặc nhân viên bảo trì thực hiện đều sẵn có và dễ dàng truy cập.
Cuối cùng, hai nhân tố quan trọng trong việc chuyển phát sản phẩm là tính khả chuyển và thao tác giữa các phần Tính khả chuyển đề cập đến khả năng của phần mềm hoạt động trên nhiều môi trường phần cứng và hệ điều hành khác nhau, cho phép thực hiện các ứng dụng một cách linh hoạt Trong khi đó, thao tác giữa các phần liên quan đến khả năng giao tiếp của các gói phần mềm với các gói hoặc thiết bị tính toán khác, đảm bảo sự tương tác và hoạt động hiệu quả trong hệ thống.
3.2.2 Cơ sở 2: Chính sách bảo trì
Các thành phần của chính sách bảo trì chính, bao gồm việc phát triển các phiên bản và thay đổi chính sách, có ảnh hưởng lớn đến sự thành công của việc bảo trì phần mềm trong suốt vòng đời của nó.
Chính sách phát triển phần mềm
Chính sách này liên quan chặt chẽ đến số lượng phiên bản phần mềm có thể hoạt động đồng thời Việc phát triển các phiên bản sau sẽ được thực hiện theo hình thức cụ thể.
Khi áp dụng chính sách "tuần tự", chỉ có một phiên bản phần mềm duy nhất được phát hành cho tất cả khách hàng Phần mềm này cần được xem xét định kỳ, và khi phiên bản mới hoàn thành, nó sẽ thay thế hoàn toàn phiên bản hiện tại cho tất cả người dùng.
Chính sách thay đổi quy định cách kiểm tra và tiêu chuẩn cho các yêu cầu thay đổi Việc kiểm tra tỉ mỉ các yêu cầu này là cần thiết, giúp nhân viên tập trung vào những thay đổi quan trọng và hữu ích Nhờ đó, công việc có thể được thực hiện hiệu quả trong thời gian hợp lý và đạt chuẩn chất lượng mong muốn.
Các thành phần chất lượng phần mềm tiền bảo trì
Giống như các thành phần SQA trong giai đoạn tiền dự án, các hoạt động SQA trước khi bảo trì cũng rất quan trọng để khởi tạo các dịch vụ bảo trì cần thiết Các bước thực hiện cần được tuân thủ một cách có hệ thống để đảm bảo hiệu quả của quá trình bảo trì.
1 Xem xét lại hợp đồng bảo trì
2 Xây dựng kế hoạch bảo trì.
3.3.1 Xem xét lại hợp đồng bảo trì
Khi xem xét hợp đồng bảo trì, cần có cái nhìn tổng quát để xác định các loại dịch vụ cần ký kết Quyết định này phụ thuộc vào từng nhóm khách hàng, bao gồm khách hàng có gói dịch vụ tùy chỉnh, khách hàng mua gói phần mềm COST, và các khách hàng nội bộ Do đó, trước khi cung cấp dịch vụ bảo trì phần mềm cho từng nhóm, hợp đồng bảo trì phải được hoàn tất để đánh giá rõ ràng các trách nhiệm bảo trì theo các điều kiện liên quan.
Giả định sự thực thi
Dịch vụ bảo trì nội bộ thường không có hợp đồng rõ ràng, dẫn đến sự không hài lòng từ cả hai phía Khách hàng mong muốn được tư vấn một cách thiện chí, trong khi nhóm phát triển lại coi việc bảo trì là nghĩa vụ bắt buộc Để giảm căng thẳng, cần thiết lập một "hợp đồng dịch vụ bên trong" để xác định rõ ràng các dịch vụ mà nhóm bảo trì cung cấp cho khách hàng Hợp đồng này sẽ giúp tránh hiểu lầm và đảm bảo rằng dịch vụ bảo trì được thực hiện một cách thỏa đáng.
Dưới đây là những mục tiêu chính trong việc xem xét lại hợp đồng bảo trì phần mềm:
Sự rõ ràng trong yêu cầu của khách hàng
Xem xét lại những phương pháp tiếp cận khác về các điều khoản trong văn bản bảo trì
Nhìn lại sự ước lượng về tài nguyên bảo trì được yêu cầu
Xem xét lại những dịch vụ bảo trì được cung cấp bởi những hợp đồng con và/hoặc khách hàng.
Xem xét lại những ước lượng về giá thành bảo trì
3.3.2 Lập kế hoạch bảo trì
Kế hoạch bảo trì cần được thiết lập cho tất cả khách hàng, cả nội bộ lẫn bên ngoài Những kế hoạch này nên cung cấp khung tổ chức cho các điều khoản bảo trì, giúp đảm bảo quy trình được thực hiện hiệu quả và đồng bộ.
Lập kế hoạch đó bao gồm những bước sau:
1 Danh sách những dịch vụ bảo trì được ký kết
Khách hàng bên trong và ngoài, số lượng người sử dụng, sự định vị vị trí cho mỗi site khách hàng.
Đặc tính của những dịch vụ bảo trì sửa đổi (xa hoặc tại chỗ).
Trách nhiệm của việc bảo trì cải thiện chức năng và khả năng thích ứng phục vụ điều khoản của mỗi khách hang.
2 Mô tả tổ chức của nhóm bảo trì
Kế hoạch tổ chức nhóm bảo trì cần chú trọng đến các yêu cầu về nhân sự, và điều này nên được xem xét một cách cẩn thận dựa trên những tiêu chuẩn cụ thể.
Số lượng thành viên nhóm được yêu cầu.
Chất lượng thành viên nhóm được yêu cầu theo công việc bảo trì, bao gồm những người quen với gói phần mềm cần được bảo trì.
Cấu trúc tổ chức của những nhóm bảo trì, bao gồm tên của những người lãnh đạo nhóm.
Định nghĩa các công việc (trách nhiệm của khách hàng, kiểu ứng dụng, ) cho mỗi nhóm.
Đào tạo khi cần thiết
3 Danh sách điều kiện thuận lợi cho bảo trì
Những điều kiện thuận lợi cho bảo trì – cơ sở hạ tầng mà có thể cung cấp dịch vụ bao gồm:
Trung tâm hỗ trợ bảo trì được trang bị đầy đủ thiết bị phần cứng và phần mềm, nhằm cung cấp dịch vụ hỗ trợ người dùng và thực hiện các sửa đổi cần thiết cho phần mềm.
Tài liệu chính thức chứa tập các tài liệu đã hoàn thành
4 Danh sách những rủi ro dịch vụ bảo trì được xác định
Rủi ro trong dịch vụ bảo trì thường phát sinh từ các tình huống không lường trước được, dẫn đến việc không thể cung cấp dịch vụ bảo trì đúng hạn Những rủi ro này cần được nhận diện và đánh giá để đảm bảo hiệu quả của quá trình bảo trì.
Thiếu nhân viên trong suốt những dịch vụ bảo trì của tổ chức, trong trung tâm hỗ trợ bảo trì cụ thể hoặc trong những ứng dụng cụ thể.
Sự không tương xứng giữa hiểu biết và trình độ chuyên môn đối với các gói phần mềm có thể ảnh hưởng đến khả năng thực hiện dịch vụ hỗ trợ người dùng và công việc bảo trì sửa đổi hiệu quả.
Những thành viên nhóm không đủ khả năng để thực hiện những công việc cải thiện chức năng cũng như khả năng thích ứng.
5 Danh sách những thủ tục và điều khiển quản lý phần mềm được yêu cầu
Hầu hết các thủ tục cần thiết để thực hiện các quy trình đều được thực hiện bởi các nhóm bảo trì sửa đổi và trung tâm hỗ trợ người dùng, nhằm giải quyết các vấn đề phát sinh.
Vận hành những ứng dụng của khách hàng.
Xử lý những bản ghi lỗi của phần mềm
Ghi chép định kỳ và liên tục những dịch vụ hỗ trợ người dùng
Ghi chép định kỳ và liên tục những dịch vụ bảo trì sửa đổi.
Đào tạo và cấp giấy chứng thực cho những thành viên bảo trì.
6 Ngân sách bảo trì phần mềm
Các ước lượng trong ngân sách bảo trì sửa đổi dựa trên kế hoạch tổ chức nhân sự, trình độ chuyên môn cần thiết và vốn đầu tư để đáp ứng nhu cầu của nhóm và các tác vụ khác Những ước lượng này phải được điều chỉnh mỗi khi có sự thay đổi về nhân sự, trình độ chuyên môn và quy trình Đồng thời, các ước lượng cho việc bảo trì cũng nhằm cải thiện chất lượng và khả năng thích ứng, được xây dựng dựa trên kỳ vọng và sự thay đổi trong quá trình thực hiện.
Các công cụ đảm bảo chất lượng phần mềm
Sự đa dạng của công cụ đảm bảo chất lượng phần mềm là cần thiết trong các chu kỳ thực hiện của vòng đời phần mềm Mỗi loại bảo trì phần mềm, bao gồm bảo trì sửa đổi, bảo trì thích ứng và bảo trì cải thiện chức năng, yêu cầu các tập công cụ SQA khác nhau Thêm vào đó, chu kỳ thực hiện phần mềm thường mở rộng việc sử dụng các công cụ SQA cơ sở và công cụ giám sát quản lý.
Phần tiếp theo sẽ nói về các nội dung sau:
1) Công cụ SQA cho bảo trì sửa lỗi
2) Công cụ SQA cho bảo trì cải thiện chức năng
3) Công cụ SQA cơ sở cho bảo trì phần mềm
4) Công cụ SQA cho giám sát quản lý bảo trì phầm mềm
3.4.1 Công cụ SQA cho bảo trì sửa lỗi
Các hoạt động bảo trì sửa lỗi đưa ra đầu tiên: a) Các dịch vụ hỗ trợ người sử dụng b) Sửa chữa phần mềm (sửa lỗi)
Các dịch vụ hỗ trợ người dùng giải quyết lỗi phần mềm và tài liệu không hoàn chỉnh hoặc mập mờ rất cần thiết Chúng giúp người dùng khắc phục những vấn đề mà họ không đủ kiến thức để tự giải quyết Dịch vụ sửa chữa phần mềm và gỡ lỗi được cung cấp trong suốt quá trình thực hiện, mặc dù thường xuyên không cần thiết Mặc dù hai loại dịch vụ này khác nhau, nhưng cả hai đều hướng tới mục tiêu chung là đảm bảo chất lượng dịch vụ Trong nhiều trường hợp, cùng một đội ngũ có thể thực hiện cả hai loại bảo trì này.
Hợp đồng giữa nhà thầu và nhà thầu phụ là công cụ quan trọng để đảm bảo chất lượng dịch vụ bảo trì và thiết lập mối quan hệ hợp tác hiệu quả Việc tích hợp công cụ SQA vào hợp đồng nhằm nâng cao chất lượng và hiệu quả công việc.
1 Các thủ tục xử lý phân loại cụ thể các cuộc gọi bảo trì.
2 Tài liệu đầy đủ về các thủ tục dịch vụ.
3 Có sẵn các bản ghi được viết tài liệu kiểm thử chuyên nghiệp của thành viên đội bảo trì của nhà thầu phụ, cho nhà thầu xem xét lại.
4 Cấp giấy phép cho nhà thầu thực hiện xem xét lại theo chu kỳ các dịch vụ bảo trì cũng như sự thỏa mãn của khách hàng.
5 Các điều kiện liên quan đến chất lượng thì yêu cầu chặt chẽ về hình phạt và sự kết thúc của ràng buộc hợp đồng con trong trường hợp cực đoan.
Một khi bảo trì sẵn sàng thực hiện, nhà thầu nên quản lý đều đặn việc xem lại dịch vụ bảo trì và sự thỏa mãn của khách hàng.
3.4.2 Công cụ SQA cho bảo trì cải thiện chức năng
Việc bảo trì cải thiện chức năng và phát triển phần mềm có nhiều điểm tương đồng, do đó, các công cụ vòng đời dự án thường được áp dụng cho bảo trì cải thiện chức năng Những công cụ này cũng có thể được sử dụng cho bảo trì thích ứng trong phạm vi rộng.
Các công cụ SQA mở rộng được áp dụng để cải thiện chức năng bảo trì bao gồm các công cụ quản lý điều khiển và cơ sở hạ tầng, sẽ được trình bày chi tiết trong các phần sau.
3.4.3 Công cụ SQA cơ sở cho bảo trì phần mềm
Các công cụ cơ sở đảm bảo chất lượng phần mềm là thành phần quan trọng trong bảo trì phần mềm, được thực thi xuyên suốt vòng đời hệ thống Sự tương đồng giữa các quy trình cải tiến và phát triển phần mềm cho phép chia sẻ các công cụ SQA cơ sở với chỉ những thay đổi nhỏ Đối với các hoạt động bảo trì sửa lỗi, cần có các công cụ SQA chuyên dụng do tính chất đặc thù của chúng Các công cụ SQA cơ sở cũng hỗ trợ cho các hoạt động bảo trì thích ứng, phù hợp với đặc điểm của chúng Những công cụ SQA cải thiện chức năng thường được áp dụng nhiều nhất, tiếp theo là các công cụ SQA cho bảo trì sửa lỗi.
Các công cụ SQA cơ sở chuyên dụng là cần thiết cho quy trình bảo trì phần mềm, đặc biệt trong việc sửa lỗi, và chúng có những đặc điểm riêng biệt Bài viết này sẽ tập trung vào các công cụ SQA cơ sở chuyên dụng thuộc các lớp khác nhau.
Các thủ tục bảo trì và các chỉ dẫn làm việc
Thiết bị hỗ trợ chất lượng
Đào tạo và cấp chứng chỉ cho đội bảo trì
Các hoạt động ngăn ngừa và sửa lỗi
Viết tài liệu và điều khiển bản ghi chất lượng
1 Các thủ tục bảo trì và chỉ dẫn làm việc
Hầu hết các quy trình bảo trì và hướng dẫn làm việc chuyên dụng đều được áp dụng cho hoạt động sửa lỗi và hỗ trợ người dùng.
Xử lý từ xa các yêu cầu cho dịch vụ trong trường hợp lỗi phần mềm
Xử lý tại chỗ các yêu cầu của khách hàng cho dịch vụ trong trường hợp phần mềm lỗi.
Dịch vụ hỗ trợ người sử dụng
Điều khiển đảm bảo chất lượng cho các hoạt động sửa lỗi phần mềm và hộ trợ người dùng
Điều tra sự thỏa mãn khách hàng.
Cấp chứng chỉ cho các thành viên đội bảo trì sửa lỗi và hỗ trợ người sử dụng.
2 Thiết bị hỗ trợ chất lượng
Bảo trì dự kiến sẽ phát triển các công cụ chuyên dụng nhằm hỗ trợ sửa lỗi phần mềm và người dùng, bao gồm các khuôn mẫu, danh sách kiểm tra và những thiết bị tương tự.
Danh sách kiểm tra các phần có thể gây ra lỗi – được áp dụng bởi nhà chuyên môn về bảo trì
Các khuôn mẫu báo cáo lỗi phần mềm được giải quyết như thế nào, bao gồm sự phát hiện của các tiến trình sửa lỗi
Danh sách kiểm tra cho việc chuẩn bị tài liệu thủ tục testing nhỏ.
3 Đào tạo và cấp chứng chỉ cho đội bảo trì Đào tạo đội bảo trì giải quyết các công việc cải thiện chức năng không khác mấy so với việc đào tạo đội phát triển phần mềm khác. Tuy nhiên, đào tạo đặc biệt và cấp chứng chỉ mang tính cốt yếu cho đội bảo trì sửa lỗi.
Đào tạo chuyên gia bảo trì sửa lỗi được thúc đẩy bởi nhu cầu hỗ trợ dịch vụ trong hợp đồng bảo trì Kế hoạch đào tạo cần cung cấp giải pháp cho yêu cầu nhân sự trong các chu kỳ trọng tải cao và thay thế nhân sự bị sa thải Trong nhiều trường hợp, việc đào tạo nhân viên bảo trì dự trữ không đủ, cần thiết phải đào tạo thêm hệ thống riêng biệt.
Yêu cầu cấp chứng chỉ cho nhân viên sửa lỗi phần mềm và hỗ trợ người dùng là yếu tố cốt lõi trong các dịch vụ này Chứng chỉ không chỉ đảm bảo chất lượng dịch vụ mà còn nâng cao sự tin cậy từ phía khách hàng.
4 Các hoạt động ngăn ngừa và sửa lỗi
Quá trình vòng đời phần mềm tạo ra thông tin quý giá như bản ghi lỗi và yêu cầu hỗ trợ khách hàng, giúp phát hiện và khắc phục sự cố, từ đó nâng cao chất lượng hệ thống phần mềm hiện tại và tương lai Để tối ưu hóa hiệu quả hoạt động, cần thiết lập các quy trình phù hợp để biểu diễn, xem xét và phân tích thông tin thu thập được, đồng thời đưa ra những đề xuất cải tiến cho các quy trình bảo trì và phát triển phần mềm.
Hai ứng dụng chung dựa vào quản lý cấu hình là: (1) sửa lỗi và
(2) sự thay thế nhóm của các phiên bản phần mềm đang được sử dụng bằng các phiên bản mới, được khởi tạo bởi tổ chức bảo trì.
1 Sửa lỗi (Failure repair): Trong vấn đề về sửa lỗi phần mềm, việc hỗ trợ cập nhật và độ tin cậy là cần thiết theo dạng của:
Thông tin quan tâm tới phiên bản hệ thống phần mềm được cài đặt tại site của khách hàng.
Bản copy code hiện thời và tài liệu của nó.
2 Thay thế nhóm (Group replacement): Thuật ngữ group trong
SQA liên quan đến tất cả khách hàng đang sử dụng cùng một phiên bản phần mềm tại cơ sở của họ Vì vậy, việc thay thế nhóm xác định rằng tất cả khách hàng sử dụng phiên bản đó sẽ nhận được bản cập nhật hoặc phiên bản mới được phát triển cùng một lúc.
CASE Tool và ảnh hưởng của nó lên chất lượng phần mềm
Đóng góp của Case Tool cho chất lượng bảo trì phần mềm
Các công cụ CASE (đặc biệt là công cụ CASE thực) có mặt trong nhiều loại của chất lượng bảo trì phần mềm theo nhiều cách khác nhau.
Bảo trì sửa chữa (Corrective mainternance)
Tài liệu phần mềm đã được cập nhật đầy đủ, cùng với CASE, sẽ hỗ trợ trong việc xác định nguyên nhân gây lỗi phần mềm một cách dễ dàng và chính xác hơn.
Các câu truy vấn cho phép xác định trước kết quả của kế hoạch sửa chữa đang đề ra một cách tốt hơn.
Sửa chữa mã nguồn hiệu quả bằng các công cụ CASE tích hợp hoặc bên ngoài giúp tự động hóa quá trình lập trình, giảm thiểu lỗi lập trình và cung cấp tài liệu sửa chữa tự động.
Bảo trì thích nghi (Adaptive mainternance)
Tài liệu phần mềm được cập nhật đầy đủ bởi các công cụ CASE giúp đánh giá khả năng thích nghi của gói phần mềm với ứng dụng và người dùng mới.
Bảo trì cải thiện chức năng (Functional improvement mainternance)
Việc sử dụng kho chứa giúp các nhà thiết kế đảm bảo tính nhất quán cho các ứng dụng mới và các cải tiến, đồng thời tích hợp hiệu quả với các hệ thống phần mềm hiện có.
Các câu truy vấn kho chứa giúp các nhà thiết kế đảm bảo tính nhất quán cho các ứng dụng và cải tiến mới, đồng thời tích hợp hiệu quả với các hệ thống phần mềm hiện có.
Các công cụ CASE tích hợp cho phép thực hiện các thay đổi và thêm chức năng một cách tự động, giúp giảm thiểu lỗi coding và tạo ra tài liệu tự động cho những thay đổi và sửa chữa.
Đóng góp của Case Tool cho quản lý dự án
Phương pháp sử dụng CASE nâng cao mang lại tính kinh tế cao hơn phương pháp thông thường
Chất lượng của việc quản lý cả hai dự án là giống nhau với việc ước lượng lịch biểu và tài nguyên dưới mức yêu cầu
Việc sử dụng các công cụ CASE thường được kỳ vọng sẽ giảm chi phí và thời gian phát triển dự án Tuy nhiên, chúng ta cần chú trọng đến vai trò của các công cụ này trong việc nâng cao chất lượng quản lý dự án, đặc biệt là trong việc kiểm soát chi phí và thời gian.
Hiện nay, việc sử dụng công cụ CASE hiện đại giúp giảm thiểu độ lệch giữa kinh phí thực thi và lịch biểu theo kế hoạch, nhờ vào khả năng ngăn ngừa lỗi và cho phép sửa lỗi nhanh chóng, dễ dàng Để nâng cao hiệu quả quản lý dự án, cần phát triển các công cụ điều khiển dự án và phương pháp luận ước lượng thời gian, kinh phí một cách cải tiến hơn.
Đảm bảo chất lượng phần mềm của các yếu tố bên ngoài cùng
Những thành phần bên ngoài đóng góp vào dự án phần mềm
Trong các dự án phát triển phần mềm hiện nay, không chỉ có tổ chức khách hàng và nhà thầu tham gia, mà còn có những người tham gia bên ngoài đóng góp mà không thuộc về nhà thầu Những người này có thể là nhà thầu phụ hoặc nhà cung cấp phần mềm COTS, và sự đóng góp của họ thường được quy định qua các thỏa thuận hoặc hợp đồng dự án Đối với các dự án lớn và phức tạp, sự tham gia của những người bên ngoài trở nên cần thiết, khi mà công việc thường được chia sẻ hoặc chuyển giao Mục tiêu là xác định các yếu tố kinh tế, kỹ thuật và cá nhân liên quan để cải thiện sự phân phối công việc trong việc hoàn thành các dự án phức tạp.
Những người tham gia bên ngoài có thể được phân chia thành 3 nhóm chính:
Nhà thầu phụ, hay còn gọi là tổ chức outsourcing, cam kết thực hiện các thành phần của một dự án, lớn hay nhỏ, tùy thuộc vào từng trường hợp cụ thể Họ thường cung cấp hợp đồng với những lợi ích nổi bật như khả năng huy động nhân viên, chuyên môn đặc biệt và giá cả cạnh tranh.
Nhà cung cấp phần mềm COTS và các module phần mềm tái sử dụng mang lại lợi ích rõ ràng trong việc tích hợp các thành phần này, giúp rút ngắn thời gian làm việc và giảm chi phí mà vẫn đảm bảo chất lượng Việc sử dụng các thành phần sẵn có sẽ được lưu trữ trong mã nguồn phát triển, dẫn đến kế hoạch làm việc ngắn hơn và phần mềm chất lượng cao hơn Phần mềm chất lượng cao không chỉ được mong đợi mà còn được kiểm tra và sửa chữa bởi các nhà phát triển, khắc phục những thiếu sót do khách hàng chỉ ra Các đặc điểm của phần mềm COTS và những vấn đề chất lượng liên quan đã được Basili và Boehm (2001) xác định.
Khách hàng đóng vai trò quan trọng trong việc thực hiện dự án, tham gia vào các phần khác nhau để áp dụng chuyên môn của họ, đáp ứng các yêu cầu giao dịch và bảo mật Việc giữ lại nhân viên phát triển nội bộ và ngăn ngừa các vấn đề bảo mật trong tương lai là cần thiết Tuy nhiên, có những hạn chế trong các điều khoản của mối quan hệ giữa khách hàng và nhà cung cấp, điều này là yếu tố thiết yếu để đảm bảo thành công cho dự án Do đó, sự tham gia của khách hàng đã trở thành một phần không thể thiếu trong nhiều dự án phát triển phần mềm và các mối quan hệ hợp đồng.
Rủi ro và lợi ích của giới thiệu người tham dự ngoài
Rủi ro chủ yếu tới chất lượng dự án liên quan với người giới thiệu tham gia từ bên ngoài trong cơ cấu của dự án là như sau:
Sự trì hoãn trong việc hoàn thành dự án thường xảy ra khi các bên tham gia bên ngoài chậm cung cấp các thành phần cần thiết cho hệ thống phần mềm Nguyên nhân chính của sự chậm trễ này thường đến từ nhà thầu phụ và khách hàng, thay vì từ các nhà cung cấp phần mềm có sẵn (COTS) Trong nhiều trường hợp, trách nhiệm của nhà thầu phụ và khách hàng trong việc kiểm soát quá trình phát triển phần mềm không đủ cao, dẫn đến tình trạng trì hoãn, thiếu thời gian cho các thay đổi và cần thiết phải tổ chức lại, từ đó ảnh hưởng tiêu cực đến tiến độ của dự án.
Các phần dự án chất lượng thấp được cung cấp bởi các thành viên bên ngoài
Các vấn đề về chất lượng phần mềm có thể được phân loại thành hai nhóm chính: sai sót và coding cũng như tài liệu không chuẩn Sai sót thường xuất hiện nhiều hơn so với số lượng mong đợi, gây ra những khó khăn trong quá trình phát triển Bên cạnh đó, việc vi phạm phong cách và cấu trúc trong coding và tài liệu có thể dẫn đến phần mềm chất lượng thấp, gây khó khăn trong giai đoạn kiểm thử và bảo trì Điều này không chỉ làm tăng thời gian kiểm tra và chỉnh sửa mà còn có thể gây ra sự chậm trễ trong dự án, đặc biệt khi các thành viên bên ngoài không hoàn thành nhiệm vụ đúng thời hạn.
Khó khăn về bảo trì trong tương lai
Một trong những thách thức lớn trong việc bảo trì phần mềm đến từ nhà thầu, người có thể gặp khó khăn do tài liệu và mã nguồn không đầy đủ hoặc không đạt tiêu chuẩn từ các thành viên bên ngoài Điều này dẫn đến chất lượng dịch vụ bảo trì kém và chi phí cao hơn cho nhà thầu Hơn nữa, khi nhiều tổ chức như nhà thầu phụ, nhà cung cấp phần mềm COTS và các bộ phận phát triển của khách hàng cùng tham gia cung cấp dịch vụ bảo trì, khách hàng sẽ phải tìm kiếm người chịu trách nhiệm cho các lỗi cụ thể mỗi khi chúng phát sinh, gây ra sự phức tạp trong quy trình bảo trì.
Mất sự kiểm soát các bộ phận của dự án
Việc kiểm soát sự phát triển phần mềm từ các thành viên bên ngoài, dù cố ý hay không, có thể dẫn đến cái nhìn lạc quan không thực tế về tình trạng dự án Sự giao tiếp với nhóm bên ngoài có thể gây gián đoạn kéo dài vài tuần, làm cản trở việc đánh giá tiến độ dự án Hệ quả là, các cảnh báo về khó khăn trong phát triển, thiếu hụt nhân sự và nhiều vấn đề khác thường đến muộn với các nhà thầu.
Nhà thầu cần nhận thức rõ ràng về những khó khăn trong dự án và xem xét kết hợp lợi ích cùng rủi ro từ các thành viên bên ngoài để đảm bảo sự thành công.
Những mục tiêu đảm bảo chất lượng về sự đóng góp người tham gia bên ngoài
Việc áp dụng công cụ SQA từ các thành viên bên ngoài có thể giúp đạt được nhiều mục tiêu quan trọng, bao gồm việc xác định và liệt kê các rủi ro đã nêu, từ đó nâng cao hiệu quả quản lý rủi ro và cải thiện chất lượng sản phẩm.
Để tránh trì hoãn hoàn thành nhiệm vụ và để đảm bảo cảnh báo sớm để tính trước sự trì hoãn
Để đảm bảo chất lượng chấp nhận được cho bộ phận triển khai, cần thiết phải thiết lập hệ thống nhận diện và tiếp nhận cảnh báo sớm về các vấn đề chất lượng trong phạm vi yêu cầu.
Để đảm bảo đủ tài liệu phục vụ cho nhóm bảo trì
Để đảm bảo liên tục, toàn diện và đáng tin cậy kiểm soát việc thực hiện người tham gia bên ngoài
Các công cụ đảm bảo chất lượng những đóng góp của các thành viên đóng góp bên ngoài
Chúng tôi khuyến khích các thành viên đóng góp bên ngoài phát triển các phương pháp SQA riêng, bao gồm các công cụ cần thiết để đảm bảo sản phẩm phần mềm và dịch vụ đạt chất lượng chấp nhận được Những công cụ này sẽ được áp dụng bởi các nhà thầu cho các thành viên đóng góp bên ngoài Trong bối cảnh này, chất lượng và thời gian là hai yếu tố quan trọng nhất cần được xác định.
Các công cụ quan trọng được sử dụng trước và trong quá trình tích hợp các thành viên đóng góp bên ngoài trong dự án phát triển phần mềm bao gồm các phương pháp quản lý dự án, nền tảng giao tiếp và các công cụ theo dõi tiến độ.
Xem xét lại tài liệu yêu cầu
Đánh giá các tiêu chuẩn chọn lựa liên quan đến các thành viên đóng góp bên ngoài
Thành lập ủy ban điều khiển gia nhập và kết hợp của dự án
Sự đóng góp trong sự xem xét thiết kế Sự đóng góp trong kiểm tra phần mềm
Cách trình bày các thủ tục đặc biệt Xác định các team leader của các nhà cung cấp và các thành viên
Chuẩn bị các báo cáo tiến trình phát triển của các hoạt động phát triển dự án
Xem xét lại các giao phẩm (các tài liệu) và acceptance tests
