Phân tích các thành phần đảm bảo chất lượng phần mềm cho dự án quản lý sách đảm bảo chất lượng phần mềmPhân tích các thành phần đảm bảo chất lượng phần mềm cho dự án quản lý sách đảm bảo chất lượng phần mềmPhân tích các thành phần đảm bảo chất lượng phần mềm cho dự án quản lý sách đảm bảo chất lượng phần mềmPhân tích các thành phần đảm bảo chất lượng phần mềm cho dự án quản lý sách đảm bảo chất lượng phần mềm
Tổng quan về đảm bảo chất lượng phần mềm
Phần mềm
1.1.1 Khái niệm về phần mềm
Phần mềm được hiểu là chương trình hoạt động trên máy tính hoặc các thiết bị chuyên dụng, nhằm hỗ trợ các chuyên gia trong từng lĩnh vực chuyên ngành thực hiện hiệu quả hơn các thao tác nghiệp vụ của họ.
Phần mềm, từ góc nhìn của chuyên viên Tin học, được cấu thành từ ba thành phần cơ bản: thành phần giao tiếp, thành phần xử lý và thành phần lưu trữ.
Phần mềm là quy tắc xử lý được thể hiện qua chương trình bao gồm mã lệnh và dữ liệu, được cài đặt vào phần cứng để tự động thực hiện các công việc thay con người Môi trường phát triển phần mềm cho phép sự hợp tác giữa nhiều đối tượng như phân tích viên, thiết kế viên, lập trình viên, kiểm thử viên, người sử dụng và quản trị viên.
Phần mềm bao gồm các thành phần:
- Chương trình máy tính (code)
- Dữ liệu cần thiết cho sự vận hành của hệ thống.
- Chương trình máy tính (code): giúp máy tính vận hành thực thi các yêu cầu
Thủ tục là một định nghĩa quan trọng trong lập trình, xác định thứ tự và lịch trình thực thi của một chương trình Nó bao gồm các phương thức triển khai và chịu trách nhiệm thực hiện các hoạt động cần thiết để tương tác với phần mềm.
Tài liệu là yếu tố cần thiết cho người phát triển, sử dụng và bảo trì, giúp tăng cường sự phối hợp và cộng tác giữa các thành viên trong đội ngũ phát triển Nó cho phép rà soát các sản phẩm lập trình và thiết kế, đồng thời cung cấp mô tả chi tiết cho ứng dụng cùng các phương pháp thích hợp cho việc sử dụng Hơn nữa, tài liệu cũng cung cấp cho đội bảo trì tất cả thông tin cần thiết về mã nguồn, công việc và cấu trúc cho từng module.
Để hệ thống hoạt động hiệu quả, cần có dữ liệu thiết yếu bao gồm các tham số đầu vào, mã nguồn và danh sách tên phù hợp với phần mềm, giúp người dùng dễ dàng thao tác Ngoài ra, dữ liệu cần thiết cũng phải đảm bảo là chuẩn dữ liệu test.
1.1.3 Đặc điểm của phần mềm
Phần mềm có đặc điểm sau:
- Không có tính chất vật lý (vô hình)
- Không bị hao mòn như phần cứng, chỉ bị lạc hậu
Sự thay đổi linh hoạt là một ưu thế nổi bật của phần mềm so với phần cứng, dẫn đến quy trình phát triển phần mềm có những đặc điểm riêng Phần mềm được sáng tạo dựa trên tư duy và ý tưởng, cho phép các nhà phát triển linh hoạt trong việc điều chỉnh và cải tiến Hơn nữa, phần mềm thường được phát hành qua nhiều phiên bản, giúp người dùng tiếp cận các tính năng mới và cải tiến liên tục.
Lỗi phần mềm và nguyên nhân
Có ba loại lỗi phần mềm chính:
Sai sót (error) trong phần mềm là sự không nhất quán giữa giá trị đầu ra và giá trị đúng tương ứng với đầu vào Nó thường xuất phát từ những nhầm lẫn hoặc hiểu sai của nhà phát triển trong quá trình phát triển phần mềm.
Lỗi là trạng thái gây ra sự cố cho hệ thống khi thực hiện chức năng nhất định Trong phần mềm, lỗi xuất hiện do những sai sót trong quá trình phát triển.
Hỏng (failure) là tình trạng phần mềm không thực hiện chức năng theo yêu cầu, dẫn đến việc chương trình không hoạt động hoặc cho kết quả không mong muốn Một hỏng hóc xảy ra khi có lỗi (fault) xuất hiện, và các lỗi này chỉ trở thành hỏng hóc khi chúng được kích hoạt trong quá trình thực thi.
Khi người dùng cố gắng áp dụng các phần mềm cụ thể nhưng gặp phải sự cố, điều này được gọi là "activated" Do đó, mọi sự cố đều xuất phát từ một lỗi.
1.2.2 Nguyên nhân gây ra lỗi phần mềm
Có 9 nguyên nhân gây lỗi phần mềm chính:
Lỗi định nghĩa yêu cầu thường xuất phát từ việc sai sót trong quá trình xác định các yêu cầu, dẫn đến việc thiếu sót những yêu cầu quan trọng và không hoàn chỉnh trong việc định nghĩa Ngoài ra, việc bao gồm các yêu cầu không cần thiết và các chức năng không thực sự cần thiết trong tương lai gần cũng góp phần làm giảm hiệu quả của dự án.
Lỗi giao tiếp giữa khách hàng và người phát triển có thể xuất phát từ việc hiểu sai các chỉ dẫn và yêu cầu trong tài liệu, dẫn đến những thay đổi không chính xác trong giai đoạn phát triển Cụ thể, việc hiểu sai các yêu cầu thay đổi được trình bày bằng văn bản hoặc lời nói có thể gây ra sự nhầm lẫn nghiêm trọng Thêm vào đó, sự thiếu quan tâm đến phản ứng của khách hàng đối với thiết kế và các đề nghị liên quan đến yêu cầu thay đổi cũng góp phần làm tăng rủi ro trong quá trình phát triển sản phẩm Việc không chú ý đến câu trả lời của khách hàng cho các câu hỏi của nhà phát triển có thể dẫn đến những hiểu lầm không đáng có, ảnh hưởng đến chất lượng cuối cùng của sản phẩm.
Sự thiếu rõ ràng trong các yêu cầu phần mềm có thể dẫn đến nhiều vấn đề nghiêm trọng Việc sử dụng mô-đun từ các dự án trước mà không phân tích kỹ lưỡng các thay đổi cần thiết để phù hợp với yêu cầu mới có thể gây ra sự cố Thêm vào đó, nhà phát triển thường quyết định bỏ qua một số chức năng quan trọng, dẫn đến việc không đáp ứng đầy đủ nhu cầu của người dùng Cuối cùng, việc xem nhẹ các yêu cầu “nhỏ” có thể tích tụ và gây ra lỗi phần mềm nghiêm trọng, ảnh hưởng đến chất lượng sản phẩm.
Lỗi thiết kế logic trong phần mềm có thể xảy ra do việc định nghĩa các yêu cầu bằng các thuật toán sai, dẫn đến quy trình định nghĩa chứa trình tự lỗi Ngoài ra, sai sót trong các định nghĩa biên và thiếu sót trong các trạng thái hệ thống phần mềm yêu cầu cũng là những vấn đề quan trọng Cuối cùng, việc thiếu sót trong định nghĩa các hoạt động trái luật trong hệ thống phần mềm cũng cần được chú ý để đảm bảo tính chính xác và hiệu quả của sản phẩm.
Lỗi coding có thể xuất phát từ nhiều nguyên nhân khác nhau, bao gồm sự hiểu lầm tài liệu thiết kế, sai sót trong ngôn ngữ lập trình, nhầm lẫn khi áp dụng CASE và các công cụ phát triển, cũng như lỗi trong việc lựa chọn dữ liệu.
Hầu hết các đơn vị phát triển đều có tài liệu và tiêu chuẩn rõ ràng để xác định nội dung, trình tự và định dạng văn bản cũng như mã code Để hỗ trợ việc tuân thủ, các đơn vị này công khai mẫu và hướng dẫn mã hóa, yêu cầu các thành viên trong nhóm phát triển phải thực hiện đúng theo các tiêu chí đã đề ra.
Trong quá trình kiểm thử, việc thiếu sót có thể xảy ra do kế hoạch kiểm thử chưa hoàn chỉnh và việc sửa chữa các lỗi phát hiện không được thực hiện đầy đủ, thường là do sơ suất hoặc áp lực thời gian.
Lỗi thủ tục là vấn đề quan trọng cần được chú ý trong các hệ thống phần mềm, nơi mà các hoạt động diễn ra qua nhiều bước Mỗi bước trong quy trình có thể xử lý nhiều loại dữ liệu khác nhau và yêu cầu kiểm tra các kết quả trung gian để đảm bảo tính chính xác và hiệu quả của toàn bộ quá trình.
Lỗi tài liệu là vấn đề thường gặp trong các đội phát triển và bảo trì, liên quan đến sai sót trong tài liệu thiết kế và hướng dẫn tích hợp của phần mềm Những lỗi này có thể dẫn đến việc phát sinh thêm lỗi trong các giai đoạn phát triển tiếp theo cũng như trong quá trình bảo trì.
Chất lượng phần mềm
1.3.1 Khái niệm về chất lượng
Chất lượng được định nghĩa là sự phù hợp với các đặc điểm kỹ thuật, tức là sản phẩm và dịch vụ phải đáp ứng các tiêu chí có thể đo lường và thỏa mãn một thông số kỹ thuật nhất định.
Chất lượng sản phẩm hoặc dịch vụ được xác định bởi khả năng đáp ứng nhu cầu và mong đợi của khách hàng Điều này có nghĩa là chất lượng không chỉ dựa vào các đặc điểm đo lường mà còn phụ thuộc vào sự hài lòng của khách hàng, cho thấy sự quan trọng của việc hiểu rõ mong muốn của họ.
1.3.2 Khái niệm về chất lượng sản phẩm phần mềm
Chất lượng sản phẩm phần mềm (Software quality) đề cập đến khả năng sản phẩm đáp ứng đầy đủ nhu cầu của người dùng, bao gồm cả tính năng và công dụng, được thể hiện rõ ràng hoặc ngầm hiểu trong các ngữ cảnh cụ thể.
Có rất nhiều định nghĩa về chất lượng phần mềm được đưa ra bởi các tổ chức, cá nhân khác nhau: Định nghĩa theo IEEE (1991):
Chất lượng phần mềm được định nghĩa là mức độ mà một hệ thống, thành phần của hệ thống hoặc quy trình đáp ứng các yêu cầu đã được xác định.
Chất lượng phần mềm được định nghĩa là mức độ mà một hệ thống, thành phần của hệ thống, hoặc quy trình có khả năng đáp ứng các yêu cầu và mong đợi của khách hàng hoặc người sử dụng.
Theo quan điểm của IEEE, việc phụ thuộc quá mức vào tài liệu đặc tả yêu cầu có thể dẫn đến rủi ro Nếu quá trình xác định yêu cầu không chính xác hoặc thiếu sót, phần mềm được phát triển theo đặc tả đó có thể không đảm bảo chất lượng, mặc dù nó có thể thực hiện đúng theo yêu cầu đã được ghi chép.
Theo quan điểm của IEEE, khách hàng thường thiếu kiến thức công nghệ, dẫn đến những yêu cầu không thực tế và thay đổi liên tục, gây khó khăn trong phát triển phần mềm Pressman (2000) định nghĩa chất lượng phần mềm là sự phù hợp với các yêu cầu về hiệu năng và chức năng, cùng với các tiêu chuẩn phát triển được ghi chép rõ ràng Định nghĩa này nhấn mạnh ba yêu cầu cần đáp ứng để đảm bảo chất lượng phần mềm trong quá trình phát triển.
- Các yêu cầu chức năng rõ ràng là nhân tố chính quyết định chất lượng đầu ra của phần mềm.
- Các tiêu chuẩn chất lượng phần mềm sẽ được nói đến trong hợp đồng.
- Các đặc tính ngầm định cần được đáp ứng trong quá trình phát triển cho dù không được nói đến rõ ràng trong hợp đồng.
Ngoài ra, còn một số khái niệm về chất lượng phần mềm:
- Là sự thỏa mãn yêu cầu (Crosby,1979), sản phẩm có đủ những đặc tính làm thỏa mãn khách hàng để tạo ra sự hài lòng về sản phẩm.
Sản phẩm không có thiếu sót được định nghĩa bởi mức độ thỏa mãn các yêu cầu đã được xác định, đồng thời cũng phản ánh khả năng đáp ứng nhu cầu và kỳ vọng của khách hàng (Juran, 1988; IEEE, 1991).
Dưới quan điểm của người sử dụng và nhà phát triển phần mềm:
Chất lượng phần mềm từ góc nhìn người sử dụng được đánh giá qua mức độ thỏa mãn các yêu cầu và mong đợi với chi phí và thời gian hợp lý Điều này bao gồm tính đúng đắn với độ đầy đủ và chính xác, tính tiện dụng với khả năng dễ học và sử dụng cùng giao diện trực quan, tính hiệu quả trong việc tối ưu sử dụng CPU, bộ nhớ và thiết bị, tính tương thích với khả năng import/export dữ liệu và tương tác, cũng như tính tiến hóa, một yếu tố quan trọng trong ngành Công nghệ Phần mềm, liên quan đến sự hoàn thiện và sự phát triển của phần cứng.
Chất lượng phần mềm từ góc nhìn của người phát triển bao gồm nhiều yếu tố quan trọng Đầu tiên, phần mềm cần phải dễ làm và dễ cập nhật, điều này có nghĩa là nó phải có khả năng tái sử dụng, tuân thủ các tiêu chuẩn hiện hành và dễ dàng tiếp nhận công nghệ mới Bên cạnh đó, tính linh hoạt trong thiết kế cũng là một yếu tố không thể thiếu Cuối cùng, an toàn là một yếu tố quan trọng, đảm bảo rằng phần mềm hoạt động hiệu quả mà không gặp phải các rủi ro bảo mật.
1.3.3 Đảm bảo chất lượng phần mềm
Để đảm bảo chất lượng sản phẩm, cần thiết lập một loạt các hoạt động có chủ đích và hệ thống Điều này sẽ tạo ra sự tin tưởng vào khả năng đạt được tiêu chuẩn chất lượng yêu cầu.
Đảm bảo chất lượng phần mềm (SQA) là quá trình đảm bảo rằng dự án phần mềm hoàn thành đúng theo đặc tả, tiêu chuẩn đã định và các chức năng yêu cầu, đồng thời không có lỗi hoặc vấn đề tiềm ẩn SQA không chỉ kiểm soát mà còn cải tiến quy trình phát triển phần mềm ngay từ đầu dự án, nhằm ngăn ngừa các sản phẩm kém chất lượng.
Mục tiêu cuối cùng của đảm bảo chất lượng phần mềm là thỏa mãn khách hàng (customer satisfaction):
Đảm bảo chất lượng phần mềm là một tập hợp các hoạt động có kế hoạch và hệ thống, cần thiết để đảm bảo sự tin cậy trong quy trình phát triển và bảo trì phần mềm Nó phải đáp ứng các yêu cầu chức năng kỹ thuật cũng như các yêu cầu quản lý, đồng thời giữ cho tiến độ và chi phí trong phạm vi ngân sách.
1.3.4 Yêu cầu đảm bảo chất lượng phần mềm
- Tuân thủ đặc tả là nền tảng để đo lường chất lượng.
- Các chuẩn (standards) được xác định trước dùng để phát triển các tiêu chí chất lượng và dẫn dắt quá trình công nghệ.
Phần mềm không chỉ cần đáp ứng các yêu cầu tường minh trong đặc tả mà còn phải tuân thủ các yêu cầu không tường minh như tính dễ sử dụng, dễ bảo trì và độ tin cậy.
1.3.5 Đảm bảo chất lượng và Kiểm soát chất lượng
Đảm bảo chất lượng (QA) là yếu tố quan trọng trong quy trình phát triển sản phẩm, chịu trách nhiệm thiết lập và giám sát các tiêu chuẩn cũng như quy trình sản xuất phần mềm QA đảm bảo rằng tất cả các bên liên quan tuân thủ nghiêm ngặt các quy định đã được định nghĩa Trong khi đó, kiểm soát chất lượng (QC) tập trung vào việc thực hiện kiểm tra chất lượng phần mềm, với hai vị trí chính là Manual QC, không yêu cầu kỹ năng lập trình, và Automation QC, yêu cầu có kiến thức lập trình.
Khảo sát, chạy thử để bảo đảm phần mềm thỏa mãn các yêu cầu về chức năng và khả năng vận hành.
Báo cáo các lỗi để các bộ phận liên quan chỉnh sửa.
Công việc của QC liên quan đến sản phẩm (product)
Mục tiêu và thách thức đảm bảo chất lượng phần mềm
1.4.1 Mục tiêu đảm bảo chất lượng phần mềm
Mục tiêu của SQA trong quy trình phát triển phần mềm bao gồm việc đảm bảo phần mềm đáp ứng các yêu cầu chức năng ở mức độ chấp nhận được, đồng thời đảm bảo rằng phần mềm tuân thủ các yêu cầu về lịch trình và ngân sách Ngoài ra, SQA cũng tập trung vào việc thiết lập và quản lý các hoạt động nhằm cải thiện và nâng cao hiệu quả của quá trình phát triển phần mềm cũng như các hoạt động liên quan đến SQA.
Các mục tiêu SQA trong giai đoạn bảo trì phần mềm bao gồm việc đảm bảo rằng các hoạt động bảo trì đáp ứng được yêu cầu chức năng ở mức độ chấp nhận được, đồng thời đảm bảo rằng các hoạt động này cũng đáp ứng được yêu cầu về lịch trình và ngân sách Ngoài ra, việc thiết lập và quản lý các hoạt động nhằm cải thiện và nâng cao hiệu quả của bảo trì phần mềm cũng là một mục tiêu quan trọng.
1.4.2 Thách thức đảm bảo chất lượng phần mềm
Sự phức tạp và khả năng vô hình của phần mềm, cùng với sự khác biệt về các đặc tính sản phẩm so với sản phẩm công nghiệp, tạo ra thách thức lớn trong việc phát triển và triển khai thành công phương pháp luận đảm bảo chất lượng phần mềm (SQA).
Không có nhà phát triển phần mềm nào dám tuyên bố sản phẩm của họ hoàn toàn không có lỗi, tương tự như các nhà sản xuất phần cứng máy tính lớn Sự từ chối này thực sự phản ánh sự khác biệt cơ bản giữa phần mềm và các sản phẩm công nghiệp khác, và những khác biệt này có thể được phân loại theo nhiều cách khác nhau.
Độ phức tạp của sản phẩm được đo bằng số lượng chế độ hoạt động mà nó cho phép Trong khi sản phẩm công nghiệp chỉ có thể có vài nghìn chế độ hoạt động từ các thiết lập máy khác nhau, một gói phần mềm điển hình lại có hàng triệu khả năng vận hành Việc xác định và phát triển chính xác vô số khả năng hoạt động này là một thách thức lớn đối với ngành công nghiệp phần mềm.
Khả năng hiển thị của sản phẩm là yếu tố quan trọng trong ngành công nghiệp, với sản phẩm công nghiệp dễ dàng nhận thấy lỗi trong quá trình sản xuất Ngược lại, sản phẩm phần mềm lại vô hình, khiến cho các khiếm khuyết không thể phát hiện ngay từ đầu, ngay cả khi chúng được lưu trữ trên đĩa hoặc CD Sự thiếu hụt của một bộ phận trong sản phẩm công nghiệp, như chiếc xe thiếu một cánh cửa, là điều dễ nhận thấy, nhưng đối với phần mềm, những lỗi này thường ẩn mình, gây khó khăn trong việc phát hiện và sửa chữa.
Quá trình sản xuất và phát triển sản phẩm bao gồm nhiều giai đoạn quan trọng, trong đó khả năng phát hiện khuyết tật trong sản phẩm công nghiệp và phần mềm có thể xuất hiện Bảng 1.1 trình bày các giai đoạn này, cho thấy tầm quan trọng của việc kiểm tra và đảm bảo chất lượng trong từng bước phát triển.
Bảng 1.1 Các giai đoạn sản xuất và phát triển sản phẩm
Nội dung Sản phẩm công nghiệp Sản phẩm phần mềm
Trong giai đoạn này, các nhà thiết kế và nhân viên đảm bảo chất lượng (QA) tiến hành kiểm tra và thử nghiệm nguyên mẫu sản phẩm nhằm phát hiện các khuyết tật.
Trong giai đoạn này, các nhóm phát triển và chuyên gia đảm bảo chất lượng phần mềm tập trung vào việc phát hiện lỗi cố hữu của sản phẩm Cuối giai đoạn, một nguyên mẫu được phê duyệt sẽ sẵn sàng cho việc tái sản xuất Đồng thời, lập kế hoạch sản xuất sản phẩm cũng được thực hiện để chuẩn bị cho giai đoạn tiếp theo.
Trong giai đoạn này, quá trình sản xuất và các công cụ được thiết kế và chuẩn bị Đối với một số sản phẩm, việc thiết kế và xây dựng dây chuyền sản xuất đặc biệt là cần thiết.
Giai đoạn này mang lại cơ hội quý báu để kiểm tra sản phẩm, giúp phát hiện những khiếm khuyết mà có thể đã bị bỏ sót trong các đánh giá và thử nghiệm trong quá trình phát triển.
Giai đoạn sản xuất phần mềm không bắt buộc, vì việc tạo bản sao và in hướng dẫn sử dụng diễn ra tự động Điều này áp dụng cho mọi loại phần mềm, từ sản phẩm tùy chỉnh với số lượng nhỏ đến các gói phần mềm được bán rộng rãi.
Sản xuất Ở giai đoạn này, các thủ tục QA được áp dụng để phát hiện lỗi của chính sản phẩm.
Như đã đề cập trước đây, việc sản xuất phần mềm chỉ giới hạn trong việc sao chép
Các khiếm khuyết trong sản phẩm thường được phát hiện sớm trong quá trình sản xuất và có thể được khắc phục bằng cách điều chỉnh thiết kế, vật liệu hoặc công cụ sản xuất Việc này giúp loại bỏ các khiếm khuyết trong các sản phẩm tương lai Tuy nhiên, khả năng phát hiện các khuyết tật trong giai đoạn này vẫn còn hạn chế.
Sự khác biệt trong việc phát hiện lỗi giữa sản phẩm phần mềm và các sản phẩm công nghiệp khác được thể hiện rõ ràng trong Bảng 1.2 Các bộ phận quan trọng của máy móc và sản phẩm tiêu dùng thường bao gồm phần mềm nhúng (phần sụn), có đặc điểm tương tự như phần mềm thông thường Khi so sánh, chúng ta thực sự đang đối chiếu sản phẩm phần mềm với các sản phẩm công nghiệp và các thành phần không phải phần mềm, bao gồm cả phần sụn Do đó, khi đề cập đến phần mềm, chúng ta bao gồm cả sản phẩm phần mềm và phần sụn Sự khác biệt trong quy trình phát triển và sản xuất giữa phần mềm và các sản phẩm công nghiệp khác yêu cầu một phương pháp luận SQA riêng biệt cho ngành phần mềm Nhu cầu về công cụ và phương pháp đặc thù cho lĩnh vực này được phản ánh qua các tiêu chuẩn như ISO 9000-3, hướng dẫn áp dụng ISO 9001 cho phát triển, cung cấp và bảo trì phần mềm Điều này càng được củng cố bởi thực tế rằng ISO chưa phát triển các hướng dẫn cụ thể cho các ngành khác, và các hướng dẫn duy nhất khác chỉ áp dụng cho dịch vụ Sự phức tạp và tính tàng hình của phần mềm, cùng với các đặc tính sản phẩm khác, đặt ra thách thức lớn cho việc phát triển và triển khai thành công phương pháp luận SQA.
Tính độc đáo của quy trình phát triển phần mềm:
Độ phức tạp cao so với các sản phẩm công nghiệp khác
Tàng hình của sản phẩm
Cơ hội để phát hiện khuyết tật (“lỗi”) chỉ giới hạn ở sản phẩm giai đoạn phát triển
Bảng 1.2 trình bày các yếu tố ảnh hưởng đến việc phát hiện lỗi trong sản phẩm phần mềm so với các sản phẩm công nghiệp khác Những đặc tính riêng biệt của sản phẩm phần mềm đóng vai trò quan trọng trong quy trình kiểm tra và phát hiện lỗi, điều này khác biệt rõ rệt so với các sản phẩm công nghiệp truyền thống.
Sản phẩm công nghệ khác Độ phức tạp của sản phẩm Thông thường, sản phẩm rất phức tạp cho phép nhiều tùy chọn hoạt động.
Mức độ phức tạp thấp hơn nhiều, cho phép tối đa vài nghìn tùy chọn hoạt động.
Khả năng hiển thị của sản phẩm Sản phẩm vô hình, không thể phát hiện ra các khiếm khuyết hoặc thiếu sót bằng mắt (ví dụ: đĩa hoặc đĩa
Sản phẩm có thể nhìn thấy được, cho phép phát hiện hiệu quả các khuyết tật bằng mắt.
CD lưu trữ phần mềm).
Các thành phần đảm bảo chất lượng phần mềm cho dự án quản lý sách
Tích hợp các hoạt động chất lượng trong vòng đời dự án
2.1.1 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à một phần 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 và xác định rõ ràng để đảm bảo chất lượng dự án đạt yêu cầu.
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, 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 với hậu quả nếu dự án không thành công.
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ới dự án và kinh nghiệm trong lĩnh vực Sự sẵn sàng hỗ trợ từ các thành viên cũng như mức độ hiểu biết giữa họ, đặc biệt là số lượng thành viên mới, ảnh hưởng đến hiệu quả làm việc của nhóm.
2.1.2 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à quy trình đánh giá các sản phẩm trung gian trong vòng đời phát triển phần mềm, nhằm kiểm tra xem các 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 chất lượng và tính khả thi của dự á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 (Validation) 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 đề ra từ ban đầ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) là bước quan trọng trong việc xác định tính phù hợp của một hệ thống hoặc thành phần cho mục đích sử dụng cụ thể.
• Đá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 phần mềm được phát triển và tài liệu hóa theo các tiêu chuẩn, 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
2.2.1 Đị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 hoặc cuộc họp này nhằm 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 cho tất cả các 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ê bình và phê chuẩn từ những người tham gia.
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 đí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.
2.2.3 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 có thể được thực hiện ở bất kỳ giai đoạn phát triển nào, khi cần hoàn thiện tài liệu phân tích hoặc thiết kế.
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á (Review Leader) cần có kiến thức và kinh nghiệm vững vàng trong việc phát triển các dự án được đánh giá Họ nên có thâm niên tương đương hoặc cao hơn so với project leader và duy trì mối quan hệ tốt với project leader cũng như đội dự án Bên cạnh đó, họ cũng cần giữ 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
2.2.4 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 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à gửi 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 are more straightforward During an inspection, reviewers read and compile their annotations, whereas in a walkthrough, they focus on reading the specific sections that will be reviewed.
Trong quá trình kiểm tra, người trình bày sẽ đọc một đoạn tài liệu và bổ sung thông tin nếu cần thiết Các bên liên quan có thể đư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ả, không nhất thiết phải là người trình bày, cung cấp cái nhìn tổng quan về dự án và các thiết kế sẽ được đánh giá 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 từng lỗi được chấp nhận, bao gồm những sai sót, phần thiếu sót và những bổ sung cần thiết.
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.
2.2.5 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 xem xét lại là không đủ.
Đảm bảo chất lượng của các thành phần bảo trì phần mềm
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ũng có thể lên đến 15 năm hoặc hơn Sự khác biệt về “tuổi thọ” của các gói phần mềm phụ thuộc vào khả năng bảo trì chất lượng Các phần mềm thành công thường có quy trình bảo trì tốt, trong khi những phần mềm khác bị hủy sớm do thiếu sự chăm sóc này Tầm quan trọng của bảo trì phần mềm được nhấn mạnh qua các tiêu chuẩn như ISO 9000 – 3, IEEE và các nghiên cứu của Oskarsson và Glass.
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.
2.3.2 Cơ sở cho chất lượng bảo trì phần mềm cao
2.3.2.1 Cơ sở 1: Chất lượng gói phần mềm
Chất lượng của gói phần mềm phụ thuộc vào sự thành thạo và nỗ lực của đội ngũ phát triển, cùng với các hoạt động đảm bảo chất lượng phần mềm (SQA) diễn ra liên tục trong quá trình phát triển Nếu gói phần mềm có chất lượng kém, điều này sẽ dẫn đến việc bảo trì không hiệu quả hoặc thậm chí không thể thực hiện.
Hai nhân tố thao tác sản phẩm:
Sự chính xác bao gồm hai khía cạnh quan trọng: đầu ra và tài liệu hướng dẫn Đầu ra cần phải được hoàn thành đúng cách, đảm bảo tính đúng đắn và phù hợp với thời điểm 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, cũng như 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ũ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ố cần xem xét lại 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 tốt nhất bằng cách tuân thủ cấu trúc phần mềm và các yêu cầu 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 bao gồm sự sẵn sàng của các chuẩn đoán hệ thống từ người dùng và các chuẩn đoán lỗi do trung tâm hỗ trợ hoặc nhân viên bảo trì cung cấp.
Cuối cùng, hai yếu tố quan trọng trong 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 thể hiện khả năng giao tiếp hiệu quả 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 mượt mà trong hệ thống.
2.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 đóng vai trò quan trọng trong việc đảm bảo thành công của quy trình bảo trì phần mềm, bao gồm sự phát triển các phiên bản và điều chỉnh chính sách phù hợp trong suốt vòng đời của phần mềm.
Chính sách phát triển phần mềm
Chính sách phát triển phần mềm liên quan chặt chẽ đến số lượng phiên bản hoạt động đồng thời Có hai phương pháp phát triển, bao gồm "tuần tự" và "cây" Trong chính sách tuần tự, chỉ có một phiên bản duy nhất được cung cấp cho tất cả khách hàng Phần mềm sẽ được xem xét định kỳ, và khi phiên bản mới hoàn thành, nó sẽ thay thế phiên bản hiện tại cho toàn bộ người dùng.
Chính sách thay đổi quy định cách kiểm tra và tiêu chuẩn cho từng yêu cầu thay đổi, đòi hỏi sự kiểm tra tỉ mỉ nhằm tập trung vào những thay đổi quan trọng và hữu ích Điều này giúp nhân viên thực hiện công việc trong thời gian hợp lý và đạt được các chuẩn chất lượng mong muốn.
2.3.3 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 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 Quy trình này bao gồm một chuỗi các bước cụ thể.
1 Xem xét lại hợp đồng bảo trì
2 Xây dựng kế hoạch bảo trì.
2.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 khái quát quan điểm mở rộng và quyết định các loại hình dịch vụ cần ký kết Những quyết định này phụ thuộc vào các loại dịch vụ khách hàng, bao gồm gói custom-made, gói phần mềm COST và khách hàng nội bộ Trước khi cung cấp dịch vụ bảo trì phần mềm cho từng nhóm khách hàng, hợp đồng bảo trì tương ứng phải được hoàn thành để đánh giá tổng số 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 nội bộ mong muốn được tham gia ý kiến, trong khi nhóm phát triển coi bảo trì là nghĩa vụ bắt buộc Để giảm bớt căng thẳng, cần xây dựng một "hợp đồng dịch vụ nội bộ" xác định rõ ràng các dịch vụ mà nhóm bảo trì cung cấp Hợp đồng này giúp loại bỏ hiểu lầm về các dịch vụ không rõ ràng và đảm bảo sự hài lòng cho khách hàng nội bộ Các mục tiêu chính trong việc xem xét lại hợp đồng bảo trì phần mềm cần được xác định rõ ràng.
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ì
2.3.3.2 Lập kế hoạch bảo trì
Kế hoạch bảo trì cần được xây dựng cho tất cả khách hàng, cả trong và ngoài, nhằm cung cấp một khung tổ chức rõ ràng cho các điều khoản bảo trì.
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 yêu cầu về nhân sự, và điều này nên được xem xét kỹ lưỡng dựa trên các 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ợ hiệu quả cho 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
CASE Tool và ảnh hưởng của nó lên chất lượng phần mềm
2.4.1 Đóng góp của Case Tool cho chất lượng phần mềm
Các công cụ CASE mang lại lợi ích đáng kể cho chất lượng sản phẩm phần mềm bằng cách giảm thiểu lỗi trong quá trình phát triển Để đánh giá hiệu quả này, chúng ta cần xem xét sự cải tiến chất lượng mà công cụ CASE có thể đạt được thông qua việc khắc phục 9 nguyên nhân chính gây ra lỗi.
Nguyên nhân gây ra lỗi
Công cụ CASE cổ điển
Lỗi trong xác định yêu cầu Hầu như không đóng góp.
Việc kiểm tra tính cố định của yêu cầu hay sự chính xác bằng máy tính gần như hiếm xảy ra.
Việc thất bại trong giao tiếp giữa khách hàng và người phát triển
Hầu như không đóng góp.
Việc xác định sự thất bại trong giao tiếp bằng máy tính thường rất khó khăn Những thất bại này chỉ có thể được nhận diện và ngăn chặn khi có sự thay đổi hoặc khi xuất hiện thông tin mới mâu thuẫn với những dữ liệu đã có.
Sự chênh lệch có chủ ý trong yêu cầu phần mềm đóng góp lớn vào việc xác định các mâu thuẫn và lỗi Những chênh lệch này có thể được phát hiện thông qua các công cụ theo dõi yêu cầu và công cụ truy vấn hiện có.
Những lỗi trong thiết kế theo logic Đóng góp lớn.
Việc thiết kế lại (re- engineering) cho phép sản sinh tự động bản thiết kế cho những hệ thống kế thừa và những bản ghi của chúng
Việc sử dụng kho lưu trữ giúp xác định các thiếu sót trong thiết kế, phát hiện những thay đổi cần thiết và nhận diện các mâu thuẫn mới so với các bản ghi đã được lưu trữ trước đó.
Lỗi trong coding có ảnh hưởng lớn đến chất lượng phần mềm Việc áp dụng các trình biên dịch và chương trình gỡ lỗi tương tác giúp phát hiện và sửa chữa lỗi hiệu quả Đồng thời, sử dụng các công cụ CASE có thể tự động tạo ra đoạn mã phù hợp với các chỉ dẫn về coding và viết tài liệu, từ đó nâng cao hiệu suất làm việc và đảm bảo tính chính xác của mã nguồn.
Những thiếu xót xảy ra trong quá trình test Đóng góp lớn.
Những công cụ kiểm tra tự động được thực hiện hồi quy và kiểm tra việc nạp một cách tự động.
Việc quản lý test và sửa lỗi máy
Các công cụ CASE được tích hợp nhằm ngăn chặn lỗi trong lập trình và giảm thiểu lỗi thiết kế Việc ứng dụng những công cụ này giúp sửa lỗi và thực hiện các thay đổi, từ đó giảm thiểu lỗi trong quá trình phát triển phần mềm và ngăn ngừa hầu hết các lỗi phát sinh.
Lỗi thủ tục Đóng góp lớn.
Việc điều khiển các phiên bản, xem xét lại và cài đặt phần mềm bằng các công cụ quản lý cấu hình Đóng góp có giới hạn.
Sử dụng tài liệu đầy đủ và luôn được cập nhật là cách hiệu quả để ngăn ngừa lỗi bảo trì do tài liệu không chính xác hoặc thiếu sót, đặc biệt khi thiết kế đã trải qua nhiều lần sửa đổi.
Lỗi tài liệu Đóng góp có giới hạn. Áp dụng duy nhất trình biên dịch văn bản vào. Đóng góp lớn.
Sử dụng hệ thống lưu trữ tự động giúp tạo ra các bản tài liệu đầy đủ và luôn được cập nhật trước mỗi lần sửa lỗi và thay đổi.
2.4.2 Đó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 maintenance)
Tài liệu của phần mềm đã được cập nhật và CASE được đưa ra đầy đủ sẽ giúp tìm ra nguyên nhân gây lỗi
(failure) của 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ã lập trình 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 coding mà không phát sinh lỗi lập trình Ngoài ra, các công cụ này còn cung cấp tài liệu tự động cho việc sửa chữa, nâng cao hiệu quả và độ chính xác trong phát triển phần mềm.
Bảo trì thích nghi (Adaptive maintenance)
Các công cụ CASE cung cấp tài liệu phần mềm đầy đủ và được cập nhật, 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 một cách chi tiết.
Bảo trì cải thiện chức năng (Functional improvement maintenance)
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 với 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 mới và các cải tiến với hệ thống phần mềm hiện có.
Việc áp dụng các công cụ CASE tích hợp giúp thực hiện các thay đổi và thêm chức năng một cách tự động, đảm bảo không có lỗi coding nào xảy ra Đồng thời, các công cụ này cũng tự động tạo ra tài liệu cho những thay đổi và sửa chữa đã thực hiện.
2.4.3 Đó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 vào 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 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 Để 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í.
