Add ngày nghỉ vào easy gantt redmine thế nào

1 ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Bài giảng cho sinh viên ngành Công nghệ thông tin Phan Thị Hoài Phương Hà Nội

2 Giới thiệu Trước những thách thức trong quá trình phát triển phần mềm, việc đảm bảo chất lượng phần mềm [Software Quality Assurance-SQA] là hết sức quan trọng, đòi hỏi phải nghiên cứu một cách nghiêm túc để thực thi hiệu quả. Tài liệu này cung cấp những kiến thức cơ bản về chất lượng phần mềm, đảm bảo chất lượng trong một dự án phát triển phần mềm. Qui trình xây dựng hệ thống đảm bảo chất lượng phần mềm cũng được trình bày trong nội dung bài giảng. Qua đó, sinh viên hiểu được cách thức xây dựng một hệ thống đảm bảo chất lượng phần mềm và vai trò của những thành viên trong hệ thống. Một số chuẩn đảm bảo chất lượng cũng được giới thiệu trong những chương cuối. Thông qua nội dung bài giảng sinh viên cũng sẽ nắm được kỹ năng rà soát và kiểm thử phần mềm. Tài liệu được soạn phần lớn dựa trên cuốn sách Software Quality Assurance From Theory to Implementation của Daniel Galin và một số tài liệu về kỹ nghệ phần mềm, nhằm hỗ trợ cho sinh viên gặp khó khăn khi đọc các tài liệu nguyên gốc tiếng Anh. Nội dung bài giảng được xây dựng trong bảy chương: Chương 1. Khái niệm về chất lượng phần mềm và các yếu tố chất lượng phần mềm Những khái niệm mở đầu của tài liệu được giới thiệu trong chương 1. Bắt đầu với khái niệm phần mềm, chất lượng phần mềm và đảm bảo chất lượng phần mềm, phần tiếp theo phân tích các yếu tố chất lượng phần mềm. Chương 2. Các thành phần chất lượng phần mềm tiền dự án Chương này trình bày những nội dung liên quan đến những thành phần đảm bảo chất lượng phần mềm tiền dự án bao gồm việc rà soát hợp đồng, kế hoạch phát triển dự án phần mềm và kế hoạch chất lượng phần mềm. Chương 3. Các thành phần SQA trong vòng đời dự án Chương 3 đề cập đến các thành phần đảm bảo chất lượng phần mềm trong vòng đời dự án phần mềm. Những nội dung được trình bày trong chương này bao gồm : phân tích một số mô hình phát triển phần mềm phổ biến, các phương pháp rà soát, bảo trì phần mềm và các công cụ CASE. Riêng kiểm thử phần mềm là bước quan trọng sẽ được trình bày riêng ở chương 4. Chương 4. Kiểm thử phần mềm Chương 4 đề cập đến kiểm thử phần mềm. Những nội dung được trình bày trong chương này bao gồm : khái niệm cơ bản, các mức kiểm thử, các kỹ thuật kiểm thử, và quá trình kiểm thử. 2

3 Chương 5. Phân loại các phần mềm phục vụ kiểm Chương 5 đề cập đến các loại thành phần được dùng trong kiểm thử phần mềm. Những nội dung được trình bày trong chương này bao gồm : các phần mềm phục vụ kiểm thử và thư viện JUnit được sử dụng rộng rãi trong kiểm thử đơn vị cho ngôn ngữ lập trình Java. Chương 6. Các thành phần cơ bản của chất lượng phần mềm Các thành phần cơ bản của chất lượng phần mềm bao gồm các thủ tục [procedure], chỉ dẫn [instruction], khuôn mẫu [templates], checklists [danh mục kiểm tra]. Đó chính là nội dung được trình bày trong phần đầu của chương 6. Phần tiếp theo sẽ trình bày các hoạt động đảm bảo chất lượng phần mềm khác như : đào tạo và cấp chứng chỉ, ngăn ngừa và sửa lỗi, quản lý cấu hình và kiểm soát tài liệu. Chương 7. Các thành phần quản lý chất lượng phần mềm Ngoài yếu tố kỹ thuật, trong các dự án phát triển phần mềm hiện đại, yếu tố quản lý đóng vai trò hết sức quan trọng. Chương 7 trình bày các vấn đề liên quan đến quản lý chất lượng phần mềm như : điều khiển tiến độ dự án, độ đo chất lượng phần mềm, chi phí chất lượng phần mềm. Chương 8. Các chuẩn, chứng chỉ và hoạt động đánh giá Chương này đề cập tới các chuẩn quản lý chất lượng như ISO 9001 và ISO , CMM và CMMI và các chuẩn tiến trình dự án như IEEE/EIA Std 12207, IEEE Std 1012, IEEE Std Chương 9. Tổ chức để đảm bảo chất lượng Trong những tổ chức lớn, quản lý nguồn nhân lực là một yếu tố quyết định sự thành công. Chương 9 đề cập đến các tác nhân tham gia vào hệ thống đảm bảo chất lượng phần mềm, vai trò, trách nhiệm của mỗi tác nhân được phân tích cụ thể trong từng đề mục của chương. Phụ lục Trình bày về các lỗi thường gặp khi viết chương trình. 3

4 MỤC LỤC Giới thiệu... 2 Chương 1. Khái niệm về chất lượng phần mềm và các yếu tố chất lượng phần mềm Đặc điểm của phần mềm và môi trường phát triển phần mềm Khái niệm phần mềm Lỗi phần mềm và phân loại nguyên nhân gây ra lỗi phần mềm Lỗi phần mềm Nguyên nhân gây ra lỗi phần mềm Định nghĩa chất lượng phần mềm và đảm bảo chất lượng phần mềm Những mục tiêu đảm bảo chất lượng phần mềm Phân loại yêu cầu phần mềm ứng với các yếu tố chất lượng phần mềm Chương 2. Các thành phần chất lượng phần mềm tiền dự án Rà soát hợp đồng Tiến trình rà soát hợp đồng và các bước thực hiện Các mục tiêu rà soát hợp đồng Thực thi rà soát hợp đồng Những khó khăn của thực hiện xem lại hợp đồng cho các đề xuất chính Khuyến cáo cho việc thực hiện duyệt lại những hợp đồng chính Các đối tượng rà soát hợp đồng Rà soát hợp đồng cho các dự án nội bộ Các kế hoạch phát triển và kế hoạch chất lượng Những mục tiêu của kế hoạch phát triển và kế hoạch chất lượng Các thành phần của kế hoạch phát triển Các thành phần của kế hoạch chất lượng Các kế hoạch phát triển và kế hoạch chất lượng cho các dự án nhỏ và các dự án nội bộ Chương 3. Các thành phần SQA trong vòng đời dự án 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ác yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm Xác minh, thẩm định và đánh giá chất lượng Rà soát Mục tiêu rà soát Những rà soát thiết kế hình thức Các rà soát ngang hàng [peer review] Các ý kiến của chuyên gia Đả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 Cơ sở cho chất lượng bảo trì cao Các thành phần chất lượng phần mềm tiền bảo trì Các công cụ đảm bảo chất lượng bảo trì phần mềm Các CASE tool và ảnh hưởng của nó lên chất lượng phần mềm Khái niệm CASE tool Đóng góp của CASE tool cho chất lượng sản phẩm phần mềm Đóng góp của CASE tool cho chất lượng bảo trì phần mềm Đóng góp của CASE tool cho quản lý dự án

5 3.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 gia Những thành phần bên ngoài đóng góp vào dự án phần mềm Rủi ro và lợi ích của giới thiệu người tham dự ngoài 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 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 4. Kiểm thử phần mềm Một số khái niệm cơ bản Ví dụ về lỗi phần mềm Đặc tả và lỗi phần mềm: Kiểm thử và tiến trình kiểm thử Các mức kiểm thử Một số thuật ngữ Các cấp độ kiểm thử Kiểm thử đơn vị - Unit Testing Kiểm thử tích hợp - Integration Testing Kiểm thử hệ thống - System Testing Kiểm thử chấp nhận - Acceptance Testing Các kỹ thuật kiểm thử Kiểm thử hộp đen - Black-box Testing Kiểm thử hộp trắng - White-box Testing [WBT] Kiểm thử gia tăng - Incremental Testing Thread Testing Bảng tóm tắt Testing Levels/ Techniques Quá trình kiểm thử Xác định tiêu chuẩn chất lượng phần mềm phù hợp Lập kế hoạch cho test Thiết kế kiểm thử [test design] Tiến trình test Thiết kế trường hợp kiểm thử [Test Case Design] Chương 5. Phân loại các phần mềm phục vụ kiểm thử Phần mềm phục vụ kiểm thử Phần mềm hỗ trợ viết tài liệu Phần mềm quản lý lỗi Công cụ kiểm thử tự động Unit test và thư viện JUnit Tổng quan về Unit Testing Tổng quan thư viện Junit Chương 6. Các thành phần cơ bản của chất lượng phần mềm Thủ tục, chỉ dẫn và các thiết bị hỗ trợ chất lượng Các thủ tục và chỉ dẫn Chuẩn bị, thực thi và cập nhật các thủ tục và chỉ dẫn Khuôn mẫu [templates] Danh mục kiểm tra [Checklists] Đào tạo đội ngũ và cấp chứng chỉ

6 Mục tiêu của đào tạo và cấp chứng chỉ Tiến trình đào tạo và cấp chứng chỉ Xác định yêu cầu kiến thức chuyên môn và sự cần thiết của đào tạo và cập nhật Xác định những nhu cầu đào tạo và cập nhật [updating] Lên kế hoạch đào tạo và chương trình cập nhật Định nghĩa các vị trí yêu cầu cấp chứng chỉ Lên kế hoạch các tiến trình cấp chứng chỉ Phân phối các chương trình đào tạo và cấp chứng chỉ Những công việc tiếp theo của việc đào tạo và cấp chứng chỉ Các hành động sửa lỗi và phòng ngừa Định nghĩa hoạt động sửa lỗi và phòng ngừa Tiến trình hành động sửa lỗi và phòng ngừa Thu thập, phân tích thông tin Phát triển các giải pháp và thực thi Tổ chức các hành động phòng ngừa và sửa lỗi Quản lý cấu hình Các thành phần cấu hình phần mềm Quản lý cấu hình phần mềm Kiểm soát sự thay đổi phần mềm Kiểm soát quản lý cấu hình phần mềm Các công cụ máy tính quản lý cấu hình phần mềm Kiểm soát tài liệu Các tài liệu kiểm soát và bản ghi chất lượng Danh sách các tài liệu được kiểm soát Chuẩn bị, phê chuẩn, lưu trữ và thu hồi tài liệu kiểm soát Chương 7. Các thành phần quản lý chất lượng phần mềm Điều khiển tiến độ dự án Các thành phần điều khiển tiến độ dự án Điều khiển tiến độ của các dự án nội bộ và các thành phần bên ngoài Thực thi kiểm soát tiến độ dự án Các công cụ kiểm soát tiến độ phần mềm Độ đo chất lượng phần mềm Các mục tiêu đo lường phần mềm và phân loại các độ đo Các độ đo tiến trình Các độ đo sản phẩm Thực hiện đo chất lượng phần mềm Những giới hạn của các độ đo phần mềm Giá thành của chất lượng phần mềm Các mục tiêu tính giá thành các độ đo chất lượng phần mềm Mô hình truyền thống tính giá chất lượng phần mềm Mô hình mở rộng tính giá chất lượng phần mềm Các vấn đề trong áp dụng tính giá các độ đo chất lượng phần mềm Chương 8. Các chuẩn, chứng chỉ và hoạt động đánh giá Các chuẩn quản lý chất lượng Phạm vi của các chuẩn quản lý chất lượng

7 ISO 9001 và ISO Các mô hình tăng trưởng khả năng phương pháp đánh giá CMM và CMMI Các chuẩn tiến trình dự án SQA IEEE/EIA Std các tiến trình vòng đời phần mềm IEEE Std 1012 xác minh và thẩm định IEEE Std 1028 rà soát Chương 9. Tổ chức để đảm bảo chất lượng Giới thiệu Cơ cấu tổ chức phát triển phần mềm Khung tổ chức phát triển phần mềm Quản lý và vai trò của quản lý trong đảm bảo chất lượng phần mềm Các hoạt động đảm bảo chất lượng của quản lý mức cao nhất Những trách nhiệm quản lý phòng ban Những trách nhiệm quản lý dự án Đơn vị SQA và các tác nhân khác trong hệ thống SQA Đơn vị SQA Những ủy viên SQA và nhiệm vụ Hội đồng SQA và nhiệm vụ Nhiệm vụ và phương thức hoạt động của diễn đàn SQA Tài liệu tham khảo Phụ lục

8 Chương 1. Khái niệm về chất lượng phần mềm và các yếu tố chất lượng phần mềm 1.1. Đặc điểm của phần mềm và môi trường phát triển phần mềm Có thể nói phần mềm là một sản phẩm đặc biệt, nó không giống như các sản phẩm công nghiệp khác nên người ta thường gọi là phát triển phần mềm. Để phân biệt sự khác nhau giữa sản phẩm phần mềm với các sản phẩm khác ta sẽ xem xét ba đặc điểm sau : [1] Độ phức tạp của sản phẩm : Độ phức tạp của sản phẩm có thể được đo bằng số lượng phương thức vận hành của sản phẩm. Một sản phẩm công nghiệp thậm chí là một máy tiên tiến cũng không cho phép nhiều hơn vài trăm phương thức vận hành. Trong khi đó, một gói phần mềm có thể có tới hàng triệu khả năng vận hành. Do đó, vấn đề đảm bảo vô số khả năng vận hành được xác định và phát triển đúng là một thách thức chính của công nghiệp phần mềm. [2] Tính trực quan của sản phầm : Trong khi các sản phẩm công nghiệp có thể nhìn thấy được, thì các sản phẩm phần mềm đều vô hình. Hầu hết các nhược điểm của một sản phầm công nghiệp đều có thể phát hiện trong tiến trình sản xuất. Hơn nữa, rất dễ dàng nhận thấy được sự khuyết thiếu một phần nào đó trong một sản phẩm công nghiệp [ ví dụ : một cái ôtô không có cửa sổ ]. Trái lại, các nhược điểm trong các sản phẩm phần mềm [được lưu trữ trong các đĩa mềm hay CD] đều không nhìn thấy được, vì vậy, thực tế là các phẩn của một gói phần mềm có thể thiếu ngay từ đầu. [3] Tiến trình sản xuất và phát triển phần mềm : Các pha trong tiến trình sản xuất một sản phẩm - Phát triển sản phẩm : trong sản xuất công nghiệp, người thiết kế và các nhân viên đảm bảo chất lượng kiểm tra nguyên mẫu để phát hiện các khuyết điểm cuả chúng. Trong sản xuất phần mềm, các chuyên gia đảm bảo chất lượng và đội phát triển có xu hướng tìm ra các lỗi sản phẩm vốn có. Kết quả cuối cùng của pha này là một nguyên mẫu đã được phê chuẩn, sẵn sàng để sản xuất. - Lập kế hoạch sản xuất sản phẩm : tại pha này, trong các ngành công nghiệp, tiến trình sản xuất và các công cụ được thiết kế và chuẩn bị. Một số dòng sản phẩm đặc biệt cần phải được thiết kế và xây dựng. Do đó, pha này đã tạo thêm cơ hội xem xét sản phẩm, và có thể phát hiện ra các khuyết điểm đã bị người rà soát và kiểm thử bỏ qua trong pha phát triển. Ngược lại, đây là pha không yêu cầu trong tiến trình sản xuất phần mềm, bởi việc sản xuất các bản copy phần mềm và in các 8

9 sách hướng dẫn phần mềm được thực hiện tự động. Điều này được áp dụng cho bất kỳ sản phẩm phần mềm nào, từ nhỏ tới lớn. - Sản xuất : Trong pha này, các thủ tục đảm bảo chất lượng trong sản xuất công nghiệp được áp dụng để phát hiện lỗi sản xuất. Các khuyết điểm trong sản phẩm được phát hiện ra ở giai đoạn đầu tiên của quá trình sản xuất có thể được hiệu chỉnh bằng một thay đổi trong thiết kế sản phẩm hoặc nguyên liệu, hay trong các công cụ sản xuất...nhờ đó có thể tránh được các khuyết điểm này trong các sản phẩm được sản xuất trong tương lai. Ngược lại, như đã nói ở phần trước, việc sản xuất phần mềm đơn giản chỉ là sao chép các sản phẩm và in các sách hướng dẫn, do đó việc phát hiện các khuyết điểm của sản phẩm rất khó khăn. Kỹ nghệ phần mềm đã có những bước phát triển đáng kể và vượt qua nhiều giai đoạn khủng hoảng. Những kết quả nghiên cứu về kỹ nghệ phần mềm đã giúp các tổ chức phát triển phần mềm một cách chuyên nghiệp hơn. Môi trường phát triển phần mềm cũng mang những nét đặc trưng riêng. Với bảy đặc trưng sau ta có thể hiểu rõ hơn về môi trường phát triển cũng như môi trường bảo trì phần mềm chuyên nghiệp: [1] Các điều kiện hợp đồng : Là kết quả của các cam kết và điều kiện trong bản hợp đồng giữa nhà phát triển phần mềm và khách hàng, các họat động bảo trì và phát triền phần mềm cần đương đầu với các vấn đề : - Một danh sách các yêu cầu chức năng được xác định mà phần mềm được phát triển và công việc bảo trì nó phải thực hiện. - Ngân sách dự án. - Thời gian biểu dự án. Nhà quản lý việc phát triển phần mềm và bảo trì dự án cần nỗ lực lớn trong việc giám sát các hoạt động để đạt được các yêu cầu của hợp đồng. [2] Mối quan hệ khách hàng nhà cung cấp : Trong suốt quá trình phát triển và bảo trì phần mềm, các hoạt động đều nằm dưới sự giám sát của khách hàng. Đội dự án phải hợp tác liên tục với khách hàng : để xem xét các yêu cầu thay đổi, để thảo luận những gì khách hàng không bằng lòng về các khía cạnh khách nhau của dự án, và để đạt được sự chấp thuận cho các thay đổi theo sáng kiến của đội phát triển. [3] Yêu cầu làm việc theo nhóm : 3 nhân tố thường thúc đẩy việc thành lập một đội dự án thay vì giao dự án cho một chuyên gia : 9

10 - Các yêu cầu về thời gian biểu. Nói cách khác, khối lượng công việc được thực hiện trong suốt thời kỳ dự án đòi hỏi sự tham gia của nhiều người nều muốn dự án hoàn thành đúng thời hạn. - Để thực hiện được dự án cần có nhiều chuyên ngành khác nhau. - Sự rà soát lại và hỗ trợ lẫn nhau của các chuyên gia sẽ làm tăng chất lượng dự án. [4] Hợp tác và phối hợp với các đội phần mềm khác : Để thực hiện được các dự án, đặc biệt là các dự án có quy mô lớn, cần nhiều hơn một đội dự án. Đây là điều rất phổ biến trong công nghiệp phần mềm. Trong các trường hợp như thế, có thể đòi hỏi phải hợp tác với : - Các đội phát triển phần mềm khác trong cùng một tổ chức. - Các đội phát triển phần cứng trong cùng một tổ chức. - Các đội phát triển phần cứng và phần mềm của các nhà cung cấp khác. - Các đội phát triển phần cứng và phần mềm của khách hàng những người tham gia một phần vào sự phát triển dự án. [5] Các giao diện với các hệ thống phần mềm khác : Ngày nay, hầu hết hệ thống phần mềm đều có các giao diện với các gói phần mềm khác nhau. Các giao diện này cho phép các dữ liệu dưới dạng điện tử được chảy giữa các hệ thống phần mềm. Có thể định nghĩa các loại giao diện chính sau đây : - Các giao diện đầu vào nơi các hệ thống phần mềm khác truyền dữ liệu tới hệ thống phần mềm của bạn. - Các giao diện đầu ra nơi hệ thống phần mềm của bạn truyền dữ liệu đã được xử lý tới các hệ thống phần mềm khác. - Các giao diện đầu vào và đầu ra tới các bảng điều khiển của máy, như trong các hệ thống kiểm soát thí nghiệm và các hệ thống y tế, thiết bị chế biến kim loại... [6] Sự cần thiết phải tiếp tục thực hiện một dự án mặc dù thành viên đội có sự thay đổi : Việc các thành viên trong đội rời khỏi đội trong thời gian phát triển dự án là khá phổ biến, do việc thăng chức với các công việc cấp cao hơn, chuyển sang một thành phố khác...người lãnh đạo đội phải thay thế các thành viên trong đội bởi các nhân viên khác hoặc bởi một nhân viên mới được tuyển dụng. Không kể đến bao nhiêu nỗ lực cần đầu tư vào việc đào tạo một thành viên mới, việc thay đổi thành viên sẽ kéo theo thời gian thực hiện dự án sẽ thay đổi. 10

11 [7] Sự cần thiết phải tiếp tục thực hiện việc bảo trì phần mềm trong một thời gian dài: Các khách hàng mua hoặc phát triển một hệ thống phần mềm mong đợi sẽ tiếp tục sử dụng nó trong một thời gian dài, thường là từ 5-10 năm. Trong suốt thời kỳ dịch vụ, cuối cùng cũng cần tới sự bảo trì. Trong hầu hết trường hợp, dịch vụ bảo trì cần được cung cấp trực tiếp bởi nhà phát triển. Trong trường hợp các phần mềm được phát triển trong nhà, các khách hàng nội bộ sẽ cùng chia sẻ vấn đề bảo trì phần mềm trong suốt thời kỳ dịch vụ của hệ thống phần mềm Khái niệm phần mềm Phần mềm bao gồm những thành phần sau đây: - Chương trình máy tính - Các thủ tục - Tài liệu liên quan - Dữ liệu cần thiết cho sự vận hành của hệ thống Mỗi thành phần phần mềm đều có chức năng riêng và chất lượng của chúng đóng góp vào chất lượng chung của phần mềm và bảo trì phần mềm như sau: 1. Chương trình máy tính được cần thiết là hiển nhiên vì chúng giúp máy tính vận hành thực thi các yêu cầu ứng dụng. 2. Những thủ tục được yêu cầu để định nghĩa theo một thứ tự và lịch biểu của một chương trình khi thực thi, phương thức được triển khai và người chịu trách nghiệm cho thực thi các hoạt động cần thiết cho việc tác động vào phần mềm 3. Nhiều kiểu tài liệu là cần thiết cho người phát triển, người sử dụng và người có nhiệm vụ duy trì. Tài liệu phát triển [báo cáo yêu cầu, báo cáo thiết kế, mô tả chương trình, v.v] cho phép sự phối hợp và cộng tác hiệu quả giữa các thành viên trong đội ngũ phát triển và hiệu quả trong việc xem lại và rà soát cá sản phẩm lập trình và thiết kế. Tài liệu sử dụng[thường là hướng dẫn sử dụng] cung cấp một sự miêu tả cho ứng dụng sẵn sàng và những phương pháp thích hợp cho họ sử dụng. Tài liệu bảo trì [tài liệu cho người phát triển] cung cấp cho đội bảo trì tất cả những thông tin yêu cầu về mã nguồn và công việc và cấu trúc cho từng module. Thông tin này được sử dụng để tìm nguyên nhân lỗi [bugs] hoặc thay đổi hoặc bổ sung thêm vào phần mềm có sẵn. 4. Dữ liệu bao gồm các tham số đầu vào, mã nguồn và danh sách tên thích hợp với phần mềm để đặc tả những cái cần thiết cho người sử dụng thao tác với hệ thống. Một kiểu khác của dữ liệu cần thiết là chuẩn dữ liệu test, sử dụng để sách định rõ những thứ thay đổi không mong muốn trong mã nguồn hoặc dữ liệu phần mềm đã từng xảy ra và những loại sự cố phần mềm nào có thể được lường trước. 11

12 1.3. Lỗi phần mềm và phân loại nguyên nhân gây ra lỗi phần mềm Lỗi phần mềm Có nhiều nguyên nhân gây ra lỗi phần mềm, biểu hiện của các lỗi cũng khác nhau ở mỗi giai đoạn phát triển phần mềm. Có ba loại lỗi phần mềm chính : - Error: Là các phần của code mà không đúng một phần hoặc toàn bộ như là kết quả của lỗi ngữ pháp, logic hoặc lỗi khác được sinh ra bởi các nhà phân tích hệ thống, một lập trình viên hoặc các thành viên khác của đội phát triển phần mềm. - Fault: Là các errors mà nó gây ra hoạt động không chính xác của phần mềm trong một ứng dụng cụ thể. - Failures: Các faults trở thành failures chỉ khi chúng được activated đó là khi người dùng cố gắng áp dụng các cầu. phần mềm cụ thể đó bị faulty. Do đó, nguồn gốc của bất kì failure nào là một errors Nguyên nhân gây ra lỗi phần mềm Việc phát hiện ra lỗi là cần thiết, nhưng tìm ra nguyên nhân gây lỗi để tránh lỗi trong tương lai mới thực sự quan trọng. Chín nguyên nhân gây ra lỗi phần mềm thống kê sau đây đã được tổng kết sau nhiều năm nghiên cứu : 1. Định nghĩa yêu cầu lỗi 2. Lỗi giao tiếp giữa khách hàng và người phát triển 3. Sự thiếu rõ ràng của các yêu cầu phần mềm 4. Lỗi thiết kế logic 5. Lỗi coding 6.Không phù hợp với tài liệu và chỉ thị coding 7. Thiếu sót trong quá trình kiểm thử 8. Lỗi thủ tục 9. Lỗi tài liệu Nội dung cụ thể mỗi nguyên nhân được xác định như sau: - Định nghĩa các yêu cầu bị lỗi Việc xác định các lỗi yêu cầu, thường do khách hàng, là một trong những nguyên nhân chính của các lỗi phần mềm. Các lỗi phổ biến nhất loại này là: Sai sót trong định nghĩa các yêu 12

13 Không có các yêu cầu quan trọng. Không hoàn chỉnh định nghĩa các yêu cầu. Bao gồm các yêu cầu không cần thiết, các chức năng mà không thực sự cần thiết trong tương lai gần. - Các lỗi trong giao tiếp giữa khách hàng và nhà phát triển Hiểu lầm trong giao tiếp giữa khách hàng và nhà phát triển là nguyên nhân bổ sung cho các lỗi ưu tiên áp dụng trong giai đoạn đầu của quá trình phát triển: Hiểu sai các chỉ dẫn của khách hàng như đã nêu trong các tài liệu yêu cầu. Hiểu sai các yêu cầu thay đổi của khách hàng được trình bày với nhà phát triển bằng văn bản trong giai đoạn phát triển. Hiểu sai của các yêu cầu thay đổi của khách hàng được trình bày bằng lời nói với nhà phát triển trong giai đoạn phát triển. Hiểu sai về phản ứng của khách hàng đối với các vấn đề thiết kế trình bày của nhà phát triển. Thiếu quan tâm đến các đề nghị của khách hàng đề cập đến yêu cầu thay đổi và khách hàng trả lời cho các câu hỏi nêu ra bởi nhà phát triển trên một phần của nhà phát triển. - Sai lệch có chủ ý từ các yêu cầu phần mềm Trong một số trường hợp, các nhà phát triển có thể cố tình đi chệch khỏi các yêu cầu trong tài liệu, hành động thường gây ra lỗi phần mềm. Các lỗi trong những trường hợp này là sản phẩm phụ của các thay đổi. Các tình huống thường gặp nhất là: Phát triển các module phần mềm Các thành phần sử dụng lại lấy từ một dự án trước đó mà không cần phân tích đầy đủ về những thay đổi và thích nghi cần thiết để thực hiện một cách chính xác tất cả các yêu cầu mới. Do thời gian hay áp lực ngân sách, nhà phát triển quyết định bỏ qua một phần của các yêu cầu các chức năng trong một nỗ lực để đối phó với những áp lực này. Nhà phát triển-khởi xướng, không được chấp thuận các cải tiến cho phần mềm,mà không có sự chấp thuận của khách hàng, thường xuyên bỏ qua các yêu cầu có vẻ nhỏ đối với nhà phát triển. Như vậy những thay đổi "nhỏ" có thể, cuối cùng, gây ra lỗi phần mềm. 13

14 - Các lỗi thiết kế logic Lỗi phần mềm có thể đi vào hệ thống khi các chuyên gia thiết kế hệ thống-các kiến trúc sư hệ thống, kỹ sư phần mềm, các nhà phân tích, vv - Xây dựng phần mềm yêu cầu. Các lỗi điển hình bao gồm: + Định nghĩa các yêu cầu phần mềm bằng các thuật toán sai lầm. + Quy trình định nghĩa có chứa trình tự lỗi. + Sai sót trong các định nghĩa biên + Thiếu sót trong các trạng thái hệ thống phần mềm được yêu cầu +Thiếu sót trong định nghĩa các hoạt động trái pháp luật trong hệ thống phần mềm - Các lỗi coding Một loạt các lý do các lập trình viên có thể gây ra các lỗi code. Những lý do này bao gồm sự hiểu lầm các tài liệu thiết kế, ngôn ngữ sai sót trong ngôn ngữ lập trình, sai sót trong việc áp dụng các CASE và các công cụ phát triển khác, sai sót trong lựa chọn dữ liệu - Không tuân thủ theo các tài liệu hướng dẫn và mã hóa Hầu hết các đơn vị phát triển có tài liệu hướng dẫn và tiêu chuẩn mã hóa riêng của mình để xác định nội dung, trình tự và định dạng của văn bản, và code tạo ra bởi các thành viên. Để hỗ trợ yêu cầu này, đơn vị phát triển và công khai các mẫu và hướng dẫn mã hóa. Các thành viên của nhóm phát triển, đơn vị được yêu cầu phải thực hiện theo các yêu cầu này. - Thiếu sót trong quá trình thử nghiệm Thiếu sót trong quá trình thử nghiệm ảnh hưởng đến tỷ lệ lỗi bằng cách để lại một số lỗi lớn hơn không bị phát hiện hoặc không phát hiện đúng. Những kết quả yếu kém từ các nguyên nhân sau đây: Kế hoạch thử nghiệm chưa hoàn chỉnh để lại phần không được điều chỉnh của phần mềm hoặc các chức năng ứng dụng và các trạng thái của hệ thống. Failures trong tài liệu và báo cáo phát hiện sai sót và lỗi lầm. Nếu không kịp thời phát hiện và sửa chữa lỗi phần mềm theo như của chỉ dẫn không phù hợp trong những lý do cho lỗi này. Không hoàn chỉnh sửa chữa các lỗi được phát hiện do sơ suất hay thời gian áp lực. 14

15 - Các lỗi thủ tục Các thủ tục trực tiếp cho người sử dụng đối với các hoạt động là cần thiết ở mỗi bước của quá trình. Chúng có tầm quan trọng đặc biệt trong các hệ thống phần mềm phức tạp, nơi các tiến trình được tiến hành một vài bước, mỗi bước trong số đó có thể có nhiều kiểu dữ liệu và cho phép kiểm tra các kết quả trung gian. - Các lỗi về tài liệu Các lỗi về tào liệu là vấn đề của các đội phát triển và bảo trì đều có sai sót trong tài liệu thiết kế và trong tài liệu hướng dẫn tích hợp trong thân của phần mềm. Những lỗi này có thể là nguyên nhân gây ra lỗi bổ sung trong giai đoạn phát triển tiếp và trong thời gian bảo trì. Cần nhấn mạnh rằng tất cả các nguyên nhân gây ra lỗi đều là con người, công việc của các nhà phân tích hệ thống, lập trình, kiểm thử phần mềm, các chuyên gia tài liệu, và thậm chí cả các khách hàng và đại diện của họ Định nghĩa chất lượng phần mềm và đảm bảo chất lượng phần mềm Theo IEEE, chất lượng phần mềm được định nghĩa như sau : Chất lượng phần mềm là:! Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được yêu cầu đã đặc tả! Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được những nhu cầu hay mong đợi của khách hàng hoặc người sử dụng. Ban đầu đảm bảo chất lượng phần mềm có mục tiêu đạt được các yêu cầu đề ra, tuy nhiên thực tế phát triển phần mềm tồn tại rất nhiều ràng buộc đòi hỏi người phát triển cần tối ưu hóa công tác quản lý. Theo Daniel Galin, khái niệm đảm bảo chất lượng phần mềm được xác định như sau : Đảm bảo chất lượng phần mềm là một tập các hoạt động đã được lập kế hoạch và có hệ thống, cần thiết để cung cấp đầy đủ sự tin cậy vào quy trình phát triển phần mềm hay quy trình bảo trì phần mềm của sản phẩm hệ thống phần mềm phù hợp với các yêu cầu chức năng kỹ thuật cũng như với các yêu cầu quản lý mà giữ cho lịch biểu và hoạt động trong phạm vi ngân sách Những mục tiêu đảm bảo chất lượng phần mềm Phát triển phần mềm luôn đi đôi với bảo trì, vì vậy các hoạt động bảo đảm chất lượng phần mềm đều có mối liên quan chặt chẽ đến bảo trì. Những mục tiêu đảm bảo 15

16 chất lượng phần mềm tương ứng với giai đoạn phát triển và bảo trì được xác định cụ thể như sau : - Phát triển phần mềm [hướng tiến trình] 1. Đảm bảo một mức độ chấp nhận được rằng phần mềm sẽ thực hiện được các yêu cầu chức năng. 2. Đảm bảo một mức đọ cấp nhận được rằng phần mềm sẽ đáp ứng được các yêu cầu về lịch biểu và ngân sách 3. Thiết lập và quản lý các hoạt động để cải thiện và nâng cao hiệu quả của phát triển phần mềm và các hoạt động SQA. - Bảo trì phần mềm [hướng sản phẩm] 1. Đảm bảo một mức độ chấp nhận được rằng các hoạt động bảo trì phần mềm sẽ đáp ứng được các yêu cầu chức năng. 2. Đảm bảo một mức đọ cấp nhận được rằng các hoạt động bảo trì phần mềm sẽ đáp ứng được các yêu cầu về lịch biểu và ngân sách 3. Thiết lập và quản lý các hoạt động để cải thiện và nâng cao hiệu quả của bảo trì phần mềm Phân loại yêu cầu phần mềm ứng với các yếu tố chất lượng phần mềm Đã có nhiều tác giả nghiên cứu về các yếu tố chất lượng phần mềm từ các yêu cầu cả nó. Theo thời gian có thể quan niệm về việc đảm bảo chất lượng phần mềm có phần thay đổi, tuy nhiên mô hình các yếu tố đảm bảo chất lượng phần mềm của McCall ra đời vào những năm 70 của thế kỷ trước vẫn còn được nhiều người nhắc đến như là cơ sở tham chiếu các yêu cầu phần mềm. Sau McCall cũng có một số mô hình được quan tâm như mô hình do Evans, Marciniak do hay mô hình của Deutsch và Willis, tuy nhiên những mô hình này chỉ bổ sung hay sửa đổi một vài yếu tố chất lượng. Theo McCall, các yếu tố chất lượng phần mềm được chia làm ba loại : - Các yếu tố hoạt động của sản phẩm bao gồm tính chính xác, tin cậy, hiệu quả, tính toàn vẹn, sử dụng được - Các yếu tố rà soát bao gồm tính bảo trì, linh hoạt, có thể test được - Các yếu tố chuyển giao bao gồm tính khả chuyển, có khả năng sử dụng lại, có khả năng giao tác. 16

17 Hình Cây mô hình yếu tố chất lượng phần mềm theo McCall Chi tiết các thuộc tính được phân tích như sau : [1] Các yếu tố vận hành sản phẩm : Sự chính xác, độ tin cậy, tính hiệu quả, tính toàn vẹn và khả năng sử dụng được : - Sự chính xác : Các yêu cầu về độ chính xác được xác định trong một danh sách các đầu ra cần thiết của hệ thống phần mềm, như màn hình hiển thị truy vấn số dư của khách hàng trong một hệ thống thông tin kế toán bán hàng Các đặc tả đầu ra thường là đa chiều, một số chiều thông dụng là : o Nhiệm vụ đầu ra [ví dụ : bản in hóa đơn bán hàng, hay đèn báo động đỏ khi nhiệt độ tăng lên trên 250 độ F] o Độ chính xác yêu cầu của các đầu ra này; chúng có thể bị ảnh hưởng bất lợi bởi các tính toán không chính xác hay các dữ liệu không chính xác. o Tính đầy đủ của thông tin đầu ra; chúng có thể bị ảnh hưởng bất lợi bởi dữ liệu không đầy đủ. o Up-to-dateness của thông tin [xác định bằng thời gian giữa sự kiện và việc xem xét hệ thống phần mềm. o Độ sẵn sàng của thông tin [thời gian đáp ứng : được định nghĩa là thời gian cần thiết để có được các thông tin yêu cầu] 17

18 o Các chuẩn cho việc code và viết tài liệu cho hệ thống phần mềm. - Độ tin cậy : Các yêu cầu về độ tin cậy giải quyết các lỗi để cung cấp dịch vụ. Chúng xác định tỷ lệ lỗi hệ thống phần mềm tối đa cho phép, các lỗi này có thể là lỗi toàn bộ hệ thống hoặc một hay nhiều chức năng riêng biệt của nó. - Tính hiệu quả : Các yêu cầu về tính hiệu quả giải quyết vấn đề về các tài nguyên phần cứng cần thiết để thực hiện tất cả các chức năng của hệ thống phần mềm với sự phù hợp của tất cả các yêu cầu khác. Các tài nguyên phần cứng chính được xem xét ở đây là khả năng xử lý của máy tính [được đo bằng MIPS triệu lệnh/giây; MHz triệu chu kỳ/giây ]; khả năng lưu trữ dữ liệu [dung lượng bộ nhớ, dung lượng đĩa được đo bằng MBs, GBs, TBs ] và khả năng truyền dữ liệu [thường được đo bằng MBPS, GBPS ]. Các yêu cầu này có thể bao gồm cả các giá trị tối đa tài nguyên phần cứng được sử dụng trong hệ thống phần mềm. Một yêu cầu khác về tính hiệu quả đó là thời gian giữa các lần phải sạc điện đối với các hệ thống nằm trên các máy tính xách tay hay các thiết bị di động. - Các yêu cầu về tính toàn vẹn giải quyết các vấn đề về bảo mật hệ thống phần mềm, các yêu cầu này để ngăn chặn sự truy cập trái phép, để phân biệt giữa phần lớn nhân viên chỉ được phép xem thông tin với một nhóm hạn chế những người được phép thêm và thay đổi dữ liệu - Các yêu cầu về khả năng sử dụng được sẽ đưa ra phạm vi của tài nguyên nhân lực cần thiết để đào tạo một nhân viên mới và để vận hành hệ thống phần mềm. [2] Các yếu tố về rà soát sản phẩm : bảo trì được, linh động và kiểm tra được : - Khả năng bảo trì được : Các yêu cầu về khả năng bảo trì được sẽ xác định người dùng và nhân viên bảo trì phải nỗ lực thế nào để xác định được nguyên nhân của các lỗi phần mềm, để sửa lỗi và để xác nhận việc sửa lỗi thành công. Các yêu cầu của yếu tố này nói tới cấu trúc modul của phần mềm, tài liệu chương trình nội bộ và hướng dẫn sử dụng của lập trình viên - Tính linh động : Các yêu cầu về tính linh động cũng bao gồm cả các khả năng và nỗ lực cần thiết để hỗ trợ các hoạt động bảo trì. Chúng gồm các nguồn lực [manday] cần thiết để thích nghi với một gói phần mềm, với các khách hàng trong cùng nghề, với các mức độ hoạt động khác nhau, với các loại sản phẩm khác nhau Các yêu cầu về yếu tố này cũng hỗ trợ các hoạt động bảo trì trở nên hoàn hảo, như thay đối và bổ sung vào phần mềm để tăng dịch vụ của nó và để thích nghi với các thay đổi trong môi trường thương mại và kỹ thuật của công ty. - Khả năng test được : Các yêu cầu về khả năng kiểm tra được nói tới việc kiểm tra sự vận hành có tốt hay không của các hệ thống thông tin. Các yêu cầu về khả 18

19 năng kiểm tra được liên quan tới các tính năng đặc biệt trong chương trình giúp người tester dễ dàng thực hiện công việc của mình hơn, ví dụ như đưa ra các kết quả trung gian. Các yêu cầu về khả năng kiểm tra được liên quan tới vận hành phần mềm bao gồm các chuẩn đoán tự động được thực hiện bởi hệ thống phần mềm trước khi bắt đầu hệ thống, để tìm hiểu xem có phải tất cả các thành phần của hệ thống phần mềm đều làm việc tốt hay không, và để có một bản báo cáo về các lỗi đã được phát hiện. Một loại khác của yêu cầu này là việc check các dự đoán tự động, được các kỹ thuật viên bảo trì sử dụng để phát hiện nguyên nhân gây lỗi phần mềm. [3] Các yếu tố về chuyển giao sản phẩm : tính lưu động [khả năng thích nghi với môi trường], khả năng tái sử dụng và khả năng cộng tác được : - Tính lưu động : các yêu cầu về tính lưu động nói tới khả năng thích nghi của hệ thống phần mềm với các môi trường khác, bao gồm phần cứng khác, các hệ điều hành khác Các yêu cầu này đòi hỏi các phần mềm cơ bản có thể tiếp tục sử dụng độc lập hoặc đồng thời trong các trường hợp đa dạng. - Khả năng tái sử dụng : Các yêu cầu về khả năng tái sử dụng nói tới việc sử dụng các modul phần mềm trong một dự án mới đang được phát triển mà các modul này ban đầu được thiết kế cho một dự án khác. Các yêu cầu này cũng cho phép các dự án tương lai có thể sử dụng một modul đã có hoặc một nhóm các modul hiện đang được phát triển. Tái sử dụng phần mềm sẽ tiết kiệm tài nguyên phát triển, rút ngắn thời gian phát triển và tạo ra các moduls chất lượng cao hơn. Chất lượng modul cao hơn là dựa trên giả định rằng hầu hết các lỗi phần mềm đều được phát hiện bởi các hoạt động đảm bảo chất lượng phần mềm thực hiện trên phần mềm ban đầu, bởi những người sử dụng phần mềm ban đầu và trong suốt những lần tái sử dụng trước của nó. Các vấn đề về tái sử dụng phần mềm đã trở thành một phần trong chuẩn công nghiệp phần mềm [IEEE,1999]. - Khả năng cộng tác : Các yêu cầu về khả năng cộng tác tập trung vào việc tạo ra các giao diện với các hệ thống phần mềm khác. Các yêu cầu về khả năng cộng tác có thể xác định tên của phần mềm với giao diện bắt buộc. Chúng cũng có thể xác định cấu trúc đầu ra được chấp nhận như một tiêu chuẩn trong một ngành công nghiệp cụ thể hoặc một lĩnh vực ứng dụng. 19

20 Chương 2. Các thành phần chất lượng phần mềm tiền dự án 2.1. Rà soát hợp đồng Một hợp đồng tồi chắc chắn là khó có thể chấp nhận được. Từ quan điểm của SQA, một hợp đồng tồi thường mô tả các yêu cầu không chặt chẽ và đưa ra kế hoạch cũng như ngân sách phi thực tế - thì sẽ dẫn đến một phần mềm có chất lượng tồi. Vì thế, một chương trình SQA cần được thực hiện để đảm bảo chất lượng phần mềm bằng cách rà soát lại những đề xuất ban đầu và sau đó là bản dự thảo hợp đồng [hoạt động rà soát hợp đồng bao gồm cả 2 hoạt động trên]. Cả hai hoạt động rà soát trên là nhằm mục đích cải thiện ngân sách và thời gian biểu, là những cơ sở cho những đề nghị và hợp đồng sau này, đồng thời có thể biết được những rủi ro tiềm năng sớm [trong mục tiêu ban đầu và trong bản dự thảo hợp đồng] Tiến trình rà soát hợp đồng và các bước thực hiện Có khá nhiều tình huống có thể giúp một công ty phần mềm [ nhà cung cấp ] ký hợp đồng với một khách hàng. Phổ biến nhất là: Tham gia trong một cuộc đấu thầu Đưa ra bản phác thảo dựa trên yêu cầu đề xuất [RFP-Request For Proposal] của khách hàng Nhận một đặt hàng từ một khách hàng của công ty Nhận một yêu cầu từ bên trong hoặc từ phòng ban khác trong một tổ chức Rà soát hợp đồng là một thành phần của SQA được nghĩ ra để hướng dẫn xem xét lại những bản dự thảo của những tài liệu đề xuất và hợp đồng. Nếu có thể, rà soát lại hợp đồng còn cung cấp sự giám sát những hợp đồng được thực hiện với những đối tác dự án tiềm năng và các nhà thầu phụ. Tiến trình ra soát có thể được chia thành hai giai đoạn: Giai đoạn 1: rà soát lại bản dự thảo đề xuất trước khi giao cho khách hàng tiềm năng [ rà soát bản dự thảo đề xuất ]. Giai đoạn này rà soát lại bản dự thảo cuối cùng và những cơ sở đề xuất: những tài liệu yêu cầu của khách hàng, chi tiết yêu cầu thêm của khách hàng và dự diễn giải các yêu cầu, các ước lượng chi phí và tài nguyên, những hợp đồng hiện tại hoặc là những bản dự thảo hợp đồng của nhà cung cấp với các đối tác và nhà thầu phụ. Giai đoạn 2: rà soát lại bản dự thảo hợp đồng trước khi kí [ rà soát bản dự thảo hợp đồng ]. Giai đoạn này rà soát lại bản dự thảo hợp đồng dựa trên đề 20

21 xuất và sự hiểu biết [bao gồm cả những thay đổi] đã đạt được trong quá trình thương thảo hợp đồng. Quá trình rà soát có thể bắt đầu khi những tài liệu dự thảo liên quan đã hoàn thành. Những cá nhân thực hiện rà soát phải xem xét kĩ lưỡng bản dự thảo trong khi đề cập đến một phạm vi toàn diện các đối tượng đang rà soát. Một danh sách kiểm tra là rất hữu ích cho việc đảm bảo xem xét hết các vấn đề liên quan. Sau khi hoàn thành giai đoạn rà soát, việc cần thiết những sự thay đổi, cái thêm vào và sự hiệu chỉnh phải được thông báo bởi đội đề xuất [sao khi rà soát bản dự thảo đề xuất] và bởi ban phụ trách về luật pháp [sau khi rà soát lại bản dự thảo hợp đồng] Các mục tiêu rà soát hợp đồng - Những mục đích của công việc rà soát bản dự thảo đề xuất Mục đích của việc rà soát bản dự thảo đề xuất là để đảm bảo rằng những hoạt động sau được thực hiện một cách thỏa đáng. 1] Những yêu cầu của khách hàng đã được giải thích chi tiết và có chú giải Những tài liệu yêu cầu đề xuất [RFP] và những tài liệu công nghệ tương tự có thể quá chung chung và mơ hồ cho những mục tiêu của dự án. Kết quả là có nhiều chi tiết cần được thêm vào từ khách hàng. Việc giải thích chi tiết những yêu cầu mập mờ và những cập nhật của chúng nên được ghi lại trong một tài liệu riêng biệt đã được sự chấp nhận của cả khách hàng và công ti phần mềm. 2] Lựa chọn những phương pháp thực hiện dự án đã được kiểm tra. Thông thường, những lựa chọn có triển vọng và phù hợp mà trên đó thể hiện một đề xuất thì đã được xem xét đầy đủ [nếu tất cả] bởi đội đề xuất. Điều kiện này đặc biệt muốn đề cập đến việc hoàn thành thay thế bao gồm tái sử dụng phần mềm, và những quan hệ đối tác hoặc là thầu lại với những công ti mà có hiểu biết chuyên môn hoặc nhân viên có chuyên môn có thể đảm bảo những điều khoản của đề xuất 3] Những khía cạnh hình thức của mối quan hệ giữa khách hàng và công ti phần mềm phải được ghi rõ. Đề xuất nên định nghĩa những thủ tục bao gồm: Sự giao tiếp với khách hàng và những kênh giao diện Việc chuyển giao dự án và tiêu chuẩn được chấp nhận Tiến trình phê chuẩn pha hình thức Phương thức tiếp theo khách hàng thiết kế và kiểm tra 21

22 Thủ tục khách hàng thay đổi yêu cầu 4] Xác định những rủi ro khi phát triển Những rủi ro khi phát triển, như không đủ kiến thức chuyên môn liên quan đến lĩnh vực nghiệp vụ của dự án hoặc cách sử dụng những công cụ phát triển yêu cầu, cần được xác định và giải quyết. 5] Ước lượng đầy đủ những tài nguyên và thời gian biểu của dự án Việc ước lượng tài nguyên đề cập đến đội ngũ nhân viên chuyên nghiệp và ngân sách của dự án, bao gồm cả chi phí cho các nhà thầu con. Việc ước lượng thời gian nên đưa vào những yêu cầu về thời gian của tất cả những bên tham gia vào dự án. Lưu ý Trong một vài tình huống, một nhà cung cấp cố ý đề nghị cung cấp một chi phí thấp, xem xét các yếu tố như tiềm năng bán hàng. Trong trường hợp này, khi mà đề xuất dựa trên ước lượng thực tế của thời gian, ngân sách và khả năng chuyên môn, những tổn thất phát sinh được coi là một mất mát có thể tính được, không phải là một hợp đồng thất bại 6] Kiểm tra năng lực của công ti đối với dự án. Việc kiểm tra này nên xem xét đến năng lực chuyên môn cũng như là khả năng sẵn sàng của những thành viên trong đội được yêu cầu và những khả năng phát triển trong thời gian đã được lập lịch. 7] Kiểm tra năng lực của khách hàng để đáp ứng những yêu cầu của mình Việc kiểm tra này đề cập đến khả năng tài chính và tổ chức của khách hàng, như tuyển dụng và đào tạo nhân sự, cài đặt phần cứng yêu cầu và nâng cấp các thiết bị liên lạc. 8] Định nghĩa đối tác và nhà thầu phụ tham gia Điều này bao gồm các vấn đề bảo đảm chất lượng, lịch trình thanh toán, phân phối thu nhập, lợi nhuận của dự án, và hợp tác giữa quản lý dự án và các đội. 9] Định nghĩa và bảo vệ quyển sở hữu. Yếu tố này có tầm quan trọng trong trường hợp tái sử dụng phần mềm, khi việc có thêm một gói mới vào hoặc có tái sử dụng phần mềm hiện nay trong tương lai hay không cần phải được quyết định. Nó cũng đề cập đến việc sử dụng các file độc quyền của các dữ liệu quan trọng cho hoạt động của hệ thống và các biện pháp an ninh. 22

23 Những mục tiêu của rà soát lại bản dự thảo đề xuất được tổng kết trong bảng sau: Những mục tiêu của việc rà soát bản dự thảo đề xuất 9 mục tiêu của việc rà soát bản dự thảo đề xuât đảm bảo rằng những hành động sau đây được thực hiện một cách thỏa đáng: 1. Những yêu cầu của khách hàng đã được giải thích chi tiết và có chú giải 2. Lựa chọn những phương pháp thực hiện dự án đã được kiểm tra 3. Những khía cạnh hình thức của mối quan hệ giữa khách hàng và công ti phần mềm phải được ghi rõ 4. Xác định những rủi ro khi phát triển 5. Ước lượng đầy đủ những tài nguyên và thời gian biểu của dự án 6. Kiểm tra năng lực của công ti đối với dự án 7. Kiểm tra năng lực của khách hàng để đáp ứng những yêu cầu của mình 8. Định nghĩa đối tác và nhà thầu phụ tham gia 9. Định nghĩa và bảo vệ quyển sở hữu - Những mục tiêu của rà soát dự thảo hợp đồng. Những mục tiêu của việc rà soát bản dự thảo hợp đồng để đảm bảo rằng những hoạt động sau đây được thực hiện một cách thỏa đáng: 1] Không có vấn đề chưa rõ ràng nào vẫn còn lại trong dự thảo hợp đồng 2] Tất cả những thỏa thuận đạt được giữa các khách hàng và công ty phải được giải thích đầy đủ và chính xác trong hợp đồng và phụ lục của nó. Những hiểu biết này được dùng để giải quyết tất cả các vấn đề chưa rõ ràng và khác biệt giữa khách hàng và công ty mà đã được đưa ra cho đến nay 3] Không có sự thay đổi, bổ sung, hoặc thiếu sót nào không được thảo luận và sự thoả thuận nên được đưa vào dự thảo hợp đồng. Việc thay đổi, dù cố ý hay không, có thể dẫn đến sự bổ sung đáng kể và những nhiệm vụ bất ngờ trong một bộ phận của nhà cung cấp. Những mục tiêu của việc rà soát lại dự thảo hợp đồng có thể được tổng kết trong bảng 5.2 Những mục tiêu của việc rà soát dự thảo hợp đồng 23

24 Ba mục tiêu của việc rà soát dự thảo hợp đồng nhằm đảm bảo những hoạt động sau đây được thực hiện một cách thỏa đáng: 1] Không có vấn đề chưa rõ ràng nào vẫn còn lại trong dự thảo hợp đồng 2] Mọi thỏa thuận đã đạt được sau khi xem xét những đề xuất phải được chú giải một cách chính xác 3] Không có sự thay đổi, bổ sung, hoặc thiếu sót đưa vào bản dự thảo hợp đồng Thực thi rà soát hợp đồng Duyệt hợp đồng khác nhau về độ lớn của chúng, tùy thuộc vào các đặc tính của dự án đề xuất. Phức tạp này có thể là kỹ thuật hoặc tổ chức. Theo đó, mức độ khác nhau của đồng nguồn lực chuyên môn được điều chỉnh phù hợp cho những duyệt hợp đồng khác nhau. Những nguồn lực chuyên môn đặc biệt cần thiết cho những đề xuất chính. - Những yêu tố ảnh hưởng tới phạm vi của một bản duyệt hợp đồng Các yếu tố quan trọng nhất của dự án xác định mức độ của hợp đồng nỗ lực xem xét lại yêu cầu là: Độ lớn của dự án, thường được đo bằng các nguồn lực man-month. Kỹ thuật phức tạp của dự án. Trình độ và sự hiểu biết của nhân viên có kinh nghiệm trong lĩnh vực của dự án. Sự hiểu biết với các lĩnh vực dự án là thường xuyên được liên kết với khả năng tái sử dụng phần mềm; trong trường hợp có thể tái sử dụng phần mềm là cao, mức độ duyệt được giảm xuống Tổ chức dự án phức tạp. Càng với số lượng lớn của các tổ chức [nghĩa là, các đối tác, nhà thầu phụ, và khách hàng] tham gia các dự án, thì càng yêu cầu công sức rà xoát hợp đồng lớn hơn. Do đó chúng tôi có thể cho rằng "đơn giản" việc duyệt hợp đồng sẽ được thực hiện bởi một người xem, họ sẽ tập trung vào một vài chủ đề và đầu tư ít thời gian để xem lại. Tuy nhiên, hợp đồng quy mô lớn có thể yêu cầu sự tham gia của một đội để nghiên cứu một loạt các vấn đề, một quá trình đòi hỏi sự đầu tư của nhiều giờ làm việc. - Tác nhân thực thi duyệt hợp 24

25 Nhiệm vụ duyệt lại hợp đồng có thể được hoàn thành bởi các cá nhân khác nhau, được liệt kê ở đây theo thứ tự tăng dần thông qua sự phức tạp của dự án: Các nhà lãnh đạo hoặc thành viên khác của nhóm đề xuất. Các thành viên của đội đề xuất. Một đội ngũ nhân viên chuyên gia bên ngoài hoặc nhân viên của công ty những người không phải là một thành viên của nhóm đề xuất. Một nhóm các chuyên gia bên ngoài. Thông thường, một nhóm rà soát lại hợp đồng bao gồm các chuyên gia bên ngoài được mời đến để đưa ra các đề xuất chuyên môn đặc biệt. Các chuyên gia có thể được mời đến để rà soát lại hợp đồng trong các tổ chức phát triển phần mềm nhỏ do không thể tìm thấy đủ các nhân viên thích hợp trong đội ngũ nhân viên của họ. - Thực hiện rà xoát lại hợp đồng cho đề xuất chính Đề xuất chính được đề nghị cho các dự án đặc trưng bởi ít nhất một số các yếu tố sau: quy mô dự án rất lớn, kỹ thuật rất cao và phức tạp, lĩnh vực chuyên môn mới, tổ chức phức tạp cao [nhận ra bởi một số lượng lớn các tổ chức, nghĩa là, đối tác, nhà thầu phụ, và khách hàng, tham gia một phần trong dự án này]. Thực hiện quá trình rà soát lại hợp đồng cho một dự án lớn thường liên quan đến đáng kể đến khó khăn của một tổ chức. Một số con đường để vượt qua những khó khăn được đề nghị ở đây, sau sự xem lại của các yếu tố giới thiệu nhiều khó khăn cho một hoành thành mịn của nhiệm vụ Những khó khăn của thực hiện xem lại hợp đồng cho các đề xuất chính Hầu hết mọi người đều đồng ý rằng xem xét lại hợp đồng là một thủ tục chính cho giảm nguy cơ thất bại của dự án lớn. Về căn bản, việc rà soát hợp đồng là khó khăn, đặc biệt là đối với những tình huống rà soát các yêu cầu đề xuất chính. Áp lực thời gian. Cả hai giai đoạn của việc xem xét hợp đồng, đề nghị xem xét lại dự thảo và xem xét dự thảo hợp đồng thường được thực hiện khi nhóm đề xuất là dưới áp lực đáng kể về thời gian. Kết quả là, mỗi giai đoạn của việc xem lại hợp đồng phải được hoàn tất trong vòng một vài ngày để giúp cho người tiếp theo điều chỉnh các văn bản được diễn ra. 25

26 Quy tắc duyệt lại hợp đồng yêu cầu phải làm việc chuyên nghiệp. Chuyên nghiệp hiệu suất của mỗi giai đoạn của việc xem lại hợp đồng yêu cầu sự đầu tư chuyên nghiệp đáng kể của các chuyên gia [số lượng thời gian yêu cầu khác nhau, tất nhiên, tùy theo bản chất của dự án]. Các thành viên tiềm năng trong nhóm rà soát Hợp đồng đều rất bận rộn. Những thành viên tiềm năng của đội duyệt hợp đồng thường là nhân viên cấp cao và các chuyên gia và họ thường cam kết thực hiện thường xuyên nhiệm vụ của họ tại tất cả thời gian được xem là cần thiết. Các chuyên gia nhàn rỗi có thể do đó là một vấn đề hậu cần quan trọng Khuyến cáo cho việc thực hiện duyệt lại những hợp đồng chính Một kế hoạch xem lại hợp đồng một cách cẩn thận quyết định thành công của nhóm rà soát hợp đồng. Các bước sau đây được thực hiện để tạo điều kiện cho quy trình rà soát. Các hợp đồng nên được rà soát theo lịch trình. Xem xét lại các hoạt động rà soát hợp đồng nên được đưa vào lịch trình chuẩn bị đề xuất, để lại đầy đủ thời gian cho việc xem lại và chỉnh tiếp theo sẽ được thực hiện. Một nhóm thực hiện rà soát lại các hợp đồng. Làm cho nó có thể làm việc theo nhóm để phân phối các khối lượng công việc giữa các thành viên trong nhóm sao cho mỗi thành viên của đội xem lại hợp đồng có thể có đủ thời gian để làm [có thể bao gồm việc chuẩn bị một bản báo cáo bằng văn bản mà tóm tắt của mình những phát hiện và kiến nghị]. Lãnh đạo của đội rà soát hợp đồng nên được bổ nhiệm. Điều quan trọng là trách nhiệm cho các tổ chức, quản lý và kiểm soát các các hoạt động rà soát hợp đồng được xác định, thích hợp hơn bằng cách bổ nhiệm một lãnh đạo của đội. Cái hoạt động của các lãnh đạo đội bao gồm: - Tuyển dụng của các thành viên trong đội - Phân phối các nhiệm vụ rà soát giữa các thành viên của nhóm nghiên cứu - Phối hợp giữa các thành viên của đội duyệt - Phối hợp giữa các đội tuyển xem xét và đề xuất 26

27 - Theo dõi các hoạt động, đặc biệt là việc tuân thủ theo lịch biểu - Tổng kết những phát hiện và phân phối chúng tớ nhóm đề nghị Lưu ý: Theo xem lại hợp đồng có thể áp đặt một khối lượng công việc đáng kể và bổ sung áp lực vào các nhóm đề xuất, nghĩ nên được trao cho khi nó có thể được thích hợp để tránh không tiến hành rà soát hợp đồng. Tình huống có thể xảy ra với các dự án quy mô nhỏ, hoặc dự án quy mô chi phí vừa và nhỏ. Các thủ tục rà soát hợp đồng nên được xác định thành những loại dự án mà rà soát lại hợp đồng là không bắt buộc. Đối với các loại khác được định nghĩa dự án "đơn giản", nó khuyến cáo rằng quyền được trao cho một người quản lý cao cấp cả. để đưa ra quyết định để xem ở đâu để thực hiện xem lại Các đối tượng rà soát hợp đồng Rà soát hợp đồng cho các dự án nội bộ "nhẹ" duyệt hợp, hoặc không ai Duyệt hợp đồng được thực hiện bởi nhiều đối tượng, dựa trên việc đánh giá mục tiêu của hợp đồng. Bảng kiểm mục [checklist] là công cụ hữu ích cho việc giúp đội xem xét để tổ chức công việc của mình và đạt được nhiều thông tin của những vấn đề liên quan. Rõ ràng là rất nhiều vấn đề trên các danh sách này là không thích hợp đối với bất kỳ dự án cụ thể. Tại cùng một thời điểm, ngay cả một danh sách kiểm tra toàn diện có thể loại trừ một số vấn đề quan trọng có liên quan đến một đề xuất dự án đã định. Đây là nhiệm vụ của đội rà soát hợp đồng, nhưng đặc biệt là của các nhà lãnh đạo, để xác định danh sách các vấn đề thích hợp cho các đề xuất dự án cụ thể. Một số lượng đáng kể, nếu không phải là đa số, các dự án phần mềm là dự án các dự án nội bộ - dự án "trong nhà" - được thực hiện bởi một bộ phận của một tổ chức cho một bộ phận của tổ chức đó. Trong trường hợp như vậy, việc đơn vị phát triển phần mềm là nhà cung cấp, trong khi các đơn vị khác có thể được coi là khách hàng. Thường xuyên, dự án phát triển phần mềm nội bộ không dựa trên những gì sẽ được xem là một mối quan hệ đầy đủ khách hàng -nhà cung cấp. Trong nhiều trường hợp, các dự án này được dựa trên các thỏa thuận chung, với thiện chí đóng vai trò quan trọng trong mối quan hệ giữa hai đơn vị. Nó sau rằng các đơn vị đang phát triển sẽ thực hiện chỉ một đoạn ngắn và 27

28 Bảng : Chuẩn dự án nội bộ và khách hàng trong cùng tổ chức Kiểu của dự án Khách hàng Ví dụ Quản trị hoặc các phần mềm thao tác dùng trong nội bộ Quản trị hoặc thao tác Hệ thống bán hàng và hàng tồn kho Hệ thống quản lý tài chính Những gói phầm phầm được dự định để bán theo kiểu phần mềm đóng gói Những vi chương trình được nhúng trong sản phẩm của công ty Thị trường phần mềm Trò chơi máy tính Phần mềm giáo dục Bộ phận phát triển điện tử và cơ khí Xử lý ngôn ngữ Công cụ điện tử và các phần mềm điều khiển Thật không may, mối quan hệ lỏng thường được đặc trưng bởi không đủ thí nghiệm các yêu cầu của dự án, lịch biểu, tài nguyên và phát triển các rủi ro. Kết quả là, những vấn đề sau đây có khả năng xảy ra: [1] Quá trình định nghĩa không tương xứng với yêu cầu dự án. [2] Nghèo nàn trong việc đánh giá yêu cầu. [3] Thời khóa biểu / lập lịch trình nghèo nàn. [4] Không tương xứng nhận thức về những nguy cơ về rủi ro. Theo danh sách này cho thấy, chúng ta có thể dễ dàng kết luận rằng in hourse, thực hiện dự án cho các khách hàng nội bộ được nhiều dễ bị thất bại hơn là những hợp đồng dự án bên ngoài. Có thể kết luận rằng mối quan hệ khách hàng-nhà cung cấp và việc xem lại hợp đồng đó được chứng minh là có hiệu quả cho các dự án bên ngoài nên được áp dụng cho các 28

29 dự án nội bộ. Các cơ hội tránh nêu trên những vấn đề tiềm năng có thể được cải thiện đáng kể bằng cách thực hiện thủ tục đó sẽ xác định: Một đề xuất phù hợp cho dự án nội bộ Áp dụng một tiến trình xem lại hợp đồng đúng cách cho các dự án nội bộ Thỏa thuận thích đáng giữa các khách hàng nội bộ và các nội bộ nhà cung cấp. - Nhược điểm của "các mối quan hệ lỏng" nội bộ dự án Vấn đề Quá trình định nghĩa không tương xứng với yêu cầu dự án Quá trình định nghĩa không tương xứng với yêu cầu dự án Thời khóa biểu / lập lịch trình nghèo nàn. Nhược điểm của khách hàng nội bộ Cài đặt lệch hướng so với yêu cầu của chương trình Hài lòng thấp Mong đợi phi hiện thực một hệ thống mềm dẻo Thiếu lịch trình ngày phân phối sản phẩm mới Nhược điểm của nhà phát triển nội bộ Tốn nhân lực để đưa ra những thay đổi có thể tránh Độ lệch lớn từ ngân sách phát triển Xung đột được gây ra bởi các yêu cầu cho việc thêm ngân sách Hoạt động phát triển dưới thời gian áp lực và khó chụi từ sản phẩm kém chất lượng Không tương xứng nhận thức về những nguy cơ về rủi ro. Chưa chuẩn bị cho những rủi ro của dự án và những hậu quả của chúng. Sự khởi đầu chậm chạm của nhân lực để khắc phục khó khăn. 29

30 2.2. Các kế hoạch phát triển và kế hoạch chất lượng Hãy tưởng tượng rằng bạn vừa được bổ nhiệm làm người đứng đầu một dự án khá lớn. Như là thường xảy ra trong ngành công nghiệp phần mềm, bạn chịu nhiều áp lực kinh khủng về thời gian từ ngày đầu tiên. Bởi vì bạn đã là thành viên của đội đề xuất và tham gia vào hầu hết các cuộc họp với đại diện của khách hàng, bạn có tự tin rằng bạn đã biết tất cả những gì là cần thiết cho công việc. Bạn định đề nghị sử dụng kế hoạch và tài liệu nội bộ mà đội đã chuẩn bị như bản kế hoạch về phát triển và chất lượng. Bạn đã chuẩn bị để dựa vào các tài liệu này bởi vì bạn biết rằng các đề nghị và ước lượng của nó, bao gồm cả thời gian biểu, yêu cầu nghiệp vụ, danh sách các tài liệu dự án,đánh giá thiết kế dự kiến, và danh sách các rủi ro khi phát triển thông qua xem xét kỹ lưỡng bởi nhóm xem xét lại hợp đồng. Vì vậy bạn có một chút thất vọng rằng tại thời điểm rất quan trọng này của dự án, phòng quản lý phát triển yêu cầu bạn ngay lập tức chuẩn bị các kế hoạch phát triển dự án mới và riêng biệt [ "Kế hoạch phát triển"] và các kế hoạch chất lượng [ "Kế hoạch chất lượng"]. Khi bạn cho rằng đề nghị hoàn thành và phụ lục của nó có thể phục vụ như là các kế hoạch yêu cầu, người quản lí nhấn mạnh rằng họ có thể cập nhật, với các chủ đề mới và toàn diện hơn để đảm bảo đầy đủ nhất của kế hoạch. "Bằng cách này," người quản lý đề cập gần như là sang một bên ", đừng quên rằng khoảng thời gian bảy tháng từ giữa các việc chuẩn bị đề nghị và ký kết hợp đồng. Đây như là một khoảng thời gian chết trong dự án của chúng ta.... " Bạn nên mong muốn rằng người quản lý của bạn là đúng. Công sức và vốn đầu tư trong việc chuẩn bị các kế hoạch phát triển và chất lượng chắc chắn sẽ mang lại lợi ích. Bạn có thể nhận ra rằng một số thành viên trong đội sẽ không sẵn sàng tại các ngày theo thời gian biểu do chậm trễ trong việc hoàn thành công việc hiện tại của họ, hay rằng các công ty tư vấn đã đồng ý cung cấp hỗ trợ chuyên môn trong một lĩnh vực chuyên môn hoá cao và quan trọng đã bị thiệt hại nặng và bị phá sản trong thời gian ngắn. Đây chỉ là hai trong các loại của các vấn đề có thể nảy sinh. Tổng kết lại, dự án cần các bản kế hoạch về phát triển và chất lượng như sau: Phải dựa trên các đề nghị sơ khai mà đã được kiểm tra lại một cách kỹ lượng và cập nhật liên tục. Phải toàn diện hơn so với đề nghị phê duyệt, đặc biệt là với quan điểm về thời gian biểu, đánh giá tài nguyên, đánh giá rủi ro và phát triển. Bao gồm bổ sung các đối tượng vắng mặt từ đề nghị phê duyệt. Chúng ta đã chuẩn bị ở giai đoạn đầu của dự án để có thể cảnh báo về khó khan trong việc lập kế hoạch, tiền năng thiếu nhân viên, các nhân tố phát triển, các vấn 30

31 đề với các cuộc họp tại các mốc quan trọng trong hợp đồng, những rủi ro phát triển được sửa đổi, Kế hoạch phát triển và chất lượng là những yếu tố chính cần thiết cho việc tuân thủ các tiêu chuẩn dự án với Đây cũng là một yếu tố quan trọng trong Capability Maturity Model [CMM] để đánh giá sự trưởng thành của tổ chức phát triển phần mềm Những mục tiêu của kế hoạch phát triển và kế hoạch chất lượng Kế hoạch, như là một quá trình, có nhiều mục tiêu, mỗi mục tiêu trong số đó có nghĩa là để chuẩn bị đầy đủ trên cơ sở sau đây: 1] Các hoạt động lập thời gian biểu phát triển sẽ dẫn đến thành công và kịp thời gian hoàn thành dự án, và ước lượng được nguồn nhân lực, yêu cầu và ngân sách. [2] Các thành viên đội tuyển dụng và việc phân bổ nguồn lực phát triển [theo lịch trình hoạt động và yêu cầu ước lượng nguồn nhân lực]. [3] Giải quyết các rủi ro phát triển. [4] Cài đặt các hoạt động được yêu cầu của SQA. [5] Cung cấp việc quản lý với dữ liệu cần thiết để kiểm soát dự án Các thành phần của kế hoạch phát triển Căn cứ vào tài liệu đề nghị, kế hoạch phát triển của dự án là chuẩn bị sẵn sàng để hoàn thành các mục tiêu trên. Các yếu tố sau đây áp dụng cho các thành phần của dự án khác nhau bao gồm kế hoạch phát triển dự án. [1] Sản phẩm dự án: Kế hoạch phát triển bao gồm các sản phẩm sau: Tài liệu thiết kế chi tiết xác định ngày hoàn thành, chỉ ra những gì được chuyển giao cho khách hàng [ "phân phối"]. Sản phẩm phần mềm [xác định ngày hoàn thành và cách cài đặt]. Đào tạo nghiệp vụ [chỉ rõ ngày tháng, người tham gia và các site]. [2] Giao diện dự án: Dự án bao gồm các giao diện: Giao tiếp với các gói phần mềm hiện có [giao diện phần mềm]. Giao tiếp với các phần mềm khác và / hoặc nhóm phát triển phần cứng đang làm việc trên cùng một hệ thống, dự án [tức là, hợp tác và phối hợp liên kết]. 31

32 Giao tiếp với phần cứng hiện tại [giao diện phần cứng]. [3] Phương pháp luận và công cụ phát triển dự án được áp dụng ở mỗi giai đoạn của dự án. Chỉ dấn thực hiện Khi đánh giá sự phù hợp của dự án với các phương pháp và công cụ phát triển được đề xuất, chúng ta cũng nên đưa vào kinh nghiệm chuyên môn của đội ngũ nhân viên, bao gồm cả nhân viên của nhà thầu phụ, thậm chí nếu tạm thời. [4] Các thủ tục và các chuẩn phát triển phần mềm: Nên có một danh sách các chuẩn bà các thủ tục được áp dụng trong dự án. [5] Sự ánh xạ các quá trình phát triển: Việc ánh xạ các quá trình phát triển bao gồm việc cung cấp các định nghĩa chi tiết cho từng giai đoạn của dự án. Những mô tả bao gồm các định nghĩa các yếu tố đầu vào và đầu ra, và các hoạt động cụ thể được lên kế hoạch. Hoạt động mô tả bao gồm: [a] Ước tính về thời gian của hoạt động. Những ước tính phụ thuộc nhiều vào kinh nghiệm thu được trong các dự án trước đó. [b]chuỗi các hoạt động hợp lý, trong đó mỗi hoạt động được thực hiện, bao gồm mô tả sự phụ thuộc của hoạt động vào các hoạt động trước đó đã hoàn thành. [c] Các kiểu nguồn lực chuyên môn cần thiết và ước lượng cần bao nhiêu nguồn lực cần thiết cho từng hoạt động. Chỉ dẫn thực hiện: Các hoạt động SQA, như xem xét lại thiết kế và test phần mềm, nên được bao gồm trong các hoạt động dự án theo lịch trình. Việc này cũng được áp dụng cho các hoạt động thiết kế và chỉnh sửa mã. Không có kế hoạch các hoạt động này có thể gây ra sự chậm trễ unanticipated trong việc khởi xướng các hoạt động tiếp theo. Một số phương pháp có sẵn cho việc lập lịch biểu và trình bày bằng hình ảnh [đồ họa] quá trình phát triển. Một trong những phương pháp phổ biến nhất là sử dụng biểu đồ Gantt, hiển thị các hoạt động khác nhau bởi các thanh ngang có độ dài tỉ lệ thuận với thời gian của hoạt động. Các thanh đại diện cho các hoạt động của mình, và được đặt theo chiều dọc, theo kế hoạch và bắt đầu kết luận của chúng. Một vài công cụ trên máy vi tính có thể chuẩn bị các biểu đồ Gantt, thêm vào để cung cấp một danh sách các hoạt động bởi thời gian cần thiết để bắt đầu và kết thúc của chúng, v..v. 32

33 Thêm một phương pháp lập kế hoạch nâng cao, như CPM và Pert, cả hai đều thuộc loại phân tích con đường quan trọng, có trình tự phụ thuộc vào thời gian hoạt động thêm vào. Chúng cho phép tính toán thời gian sớm nhất và muộn nhất được chấp nhận cho mỗi hoạt động. Sự khác nhau giữa các thời gian bắt đầu phụ thuộc vào tính linh hoạt của các hoạt động được lập lịch. Đặc biệt chú ý đến các hoạt động thiếu thời gian biểu linh hoạt [được gọi là các hoạt động critical path ], và hoàn thành vội vaǹg có thể gây chậm trễ trong việc ký kết của toàn bộ dự án. Một số gói phần mềm, sử dụng kết hợp các phương pháp, hỗ trợ việc lập kế hoạch, báo cáo và theo dõi thời gian biểu của dự án. Một ví dụ về một gói phần mềm của loại hình này là dự Microsoft Project. Để thảo luận chi tiết hơn về việc lập lịch, hãy tham khảo các sách viết về quản lý dự án. [6] Các mốc dự án: Đối với mỗi mốc quan trọng, thời gian hoàn thành và các sản phẩm của dự án [các tài liệu và mã] được xác định. [7] Tổ chức nhân viên trong dự án: Kế hoạch tổ chức bao gồm: Cơ cấu tổ chức: định nghĩa các đội dự án và nhiệm vụ của họ, bao gồm các đội được bao gồm cả các công nhân của nhà thầu phụ. Các yêu cầu chuyên môn: chứng chỉ chuyên môn, kinh nghiệm trong một ngôn ngữ lập trình cụ thể hoặc công cụ phát triển, kinh nghiệm với một sản phẩm phần mềm cụ thể và các loại,.. v..v. Số thành viên của nhóm cần thiết cho từng thời kỳ, theo các hoạt động đã được lập lịch Dự kiến các đội sẽ bắt đầu hoạt động của họ vào các thời điểm khác nhau, và kích thước đội của họ có thể khác nhau tại mỗi khoảng thời gian, tùy thuộc vào các hoạt động đã được lập kế hoạch. Tên của các nhà lãnh đạo đội và các thành viên nhóm. Những khó khăn được dự kiến sẽ phát sinh đối với việc giao lâu dài của nhân viên để các đội vì sự thay đổi trong tập unanticipated hiện tại của họ. Vì vậy, tên của các nhân viên được yêu cầu giúp theo dõi sự tham gia của họ như thành viên của nhóm. Chỉ dẫn thực hiện: Tính sẵn có lâu dài của nhân viên dự án nên được kiểm tra cẩn thận. Chậm lại trong hoàn thành nhiệm vụ trước đây có thể dẫn đến sự chậm trễ trong việc gia nhập nhóm dự án, trong đó tăng rủi ro không họp lại được tại các mốc quan trọng của dự án. Ngoài ra, 33

34 nhân viên bốc hơi "" gây ra bởi chức và / hoặc các chương trình khuyến mại, hiện tượng đó là đặc biệt thường xuyên trong ngành công nghiệp phần mềm, có thể gây ra tình trạng thiếu nhân viên. Vì vậy, ước lượng khả năng sẵn có của nhân viên nên được kiểm tra định kỳ để tránh những "ngạc nhiên". Cảnh báo sớm về tình trạng thiếu nhân viên bất khả kháng, làm cho nó dễ dàng để giải quyết vấn đề hơn. [8] Các nhân tố phát triển: Các nhân tố phát triển bắt buộc bao gồm phần cứng, phần mềm và công cụ phát triển phần cứng, không gian văn phòng, và các mặt hàng khác. Đối với từng nhân tố, khoảng thời gian cần thiết cho việc sử dụng nó nên được ghi trên thời gian biểu. [9] Các rủi ro phát triển: Rủi ro phát triển vốn có trong bất kỳ dự án. Để hiểu pervasiveness của chúng, và làm thế nào có thể kiểm soát được chúng,đầu tiên chúng ta phải xác định các khái niệm. Một rủi ro phát triển là "một tiểu bang hoặc tài sản của một công việc hoặc môi trường phát triển, trong đó, nếu bỏ qua, sẽ tăng khả năng thất bại của dự án" [Ropponen và Lyytinen, 2000].Các rủi ro phát triển tiêu biểu là: Các khoảng trống công nghệ - Thiếu kiến thức chuyên môn phù hợp và đầy đủ và kinh nghiệm để thực hiện các nhu cầu của các hợp đồng phát triển. Thiếu nhân viên - hụt Unanticipated của đội ngũ nhân viên chuyên nghiệp. Sự phụ thuộc lẫn nhau của các yếu tố tổ chức - Các khả năng của các nhà cung cấp phần cứng hoặc phần mềm chuyên dụng của nhà thầu phụ, ví dụ,họ sẽ không thực hiện nghĩa vụ của họ như trên thời gian biểu. Hệ thống hoạt động quản lý rủi ro nên được khởi xướng để đối phó với chúng. Quy trình quản lý rủi ro bao gồm các hoạt động sau đây: nhận biết rủi ro, đánh giá rủi ro, lập kế hoạch hành động quản lý rủi ro [RMAs], thực hiện RMAs, và giám sát các RMAs. Phần mềm RMAs được đưa vào kế hoạch phát triển. Tầm quan trọng ngày càng tăng của phần mềm quản lý rủi ro được thể hiện trong mô hình xoắn ốc của các vòng đời phần mềm. Để đối phó với các loại rủi ro, một giai đoạn đặc biệt dành riêng để đánh giá rủi ro phần mềm được chỉ định cho mỗi chu kỳ xoắn ốc[boehm, 1988, 1998]. [10] Các phương pháp kiểm soát: Để kiểm soát việc thực hiện dự án, quản lý dự án và quản lý phòng áp dụng một loạt các giám sát thực tiễn khi chuẩn bị báo cáo tiến độ và phối hợp với các cuộc họp. [11] Ước lượng chi phí dự án: 34

35 Ước lượng chi phí dự án là dựa trên đề xuất dự toán chi phí, sau đó là xem xét kỹ lưỡng về sự liên quan tiếp tục của chúng dựa trên các số ước lượng tài nguyên cập nhật con người, thương lượng hợp đồng với nhà thầu phụ và nhà cung cấp, và..v..v. Ví dụ, một phần của dự án, kế hoạch sẽ được thực hiện bởi một nhóm phát triển nội bộ, cần phải được thực hiện bởi một nhà thầu phụ, do độ chưa sẵn sàng của đội. Một sự thay đổi của bản chất này thường được tham gia vào một ngân sách bổ sung đáng kể Các thành phần của kế hoạch chất lượng Tất cả hay một số mục sau đây, tùy thuộc vào các dự án, bao gồm các thành phần của một kế hoạch quản lý chất lượng dự án : [1] Những mục tiêu của quản lý chất lượng Thuật ngữ quality goals dùng để chỉ các yêu cầu chất lượng thực chất của việc phát triển hệ thống phần mềm. Đơn vị định lượng được ưa thích hơn so với các đơn vị định tính khi lựa chọn mục tiêu chất lượng, bởi chúng cung cấp cho nhà phát triển các đánh giá khách quan hơn về hiệu suất phần mềm trong suốt quá trình phát triển tiến trình và kiểm thử hệ thống. Tuy nhiên, không chỉ có một loại mục tiêu thích ứng với tất cả. Các thể thay thế chất lượng với đơn vị định lượng được minh họa trong ví dụ sau đây Ví dụ Một hệ thống phần mềm phục vụ các công việc văn phòng của một nhà máy sản xuất điện được phát triển.hệ thống trợ giúp công việc văn phòng [ HDS Help desk system ] được dự định hoạt động 100 giờ mỗi tuần. Đội quản lý chất lượng phần mềm được yêu cầu chuẩn bị trước 1 danh sách các mục tiêu chất lượng định lượng phù hợp với những yêu cầu chất lượng nhất định, như thể hiện trong bảng sau HDS qualitative requirements [yêu cầu chất lượng ] Các mục tiêu định lượng chất lượng liên quan HDS: thân thiện với người sử dụng HDS: rất tin cậy HDS: hoạt động liên tục Một thao tác mới trợ giúp công việc văn phòng có thể học chi tiết theo một khóa học kéo dài ít hơn 8 giờ, và làm chủ hoạt động trong ít hơn 5 ngày làm việc HDS luôn sẵn sàng trên 99,5% [thời gian chết của HDS không được quá 30 phút mỗi tuần ] Thời gian phục hồi hệ thống không được quá 10 phút trong trường hợp HDS bị lỗi 35

36 HDS: có hiệu quả cao HDS: cung cấp dịch vụ chất lượng cao cho khách hàng Một thao tác HDS phải có khả năng xử lý ít nhất 100 yêu cầu của khách hàng trong 8 giờ thay đồi Thời gian chờ đợi cho một thao tác phản hồi không vượt quá 30 giây trong 99% lời yêu cầu.những thành công của mục tiêu này phụ thuộc vào sự kết hợp các tính năng của phần mềm và số lượng cài đặt và vận hành các trạm làm việc Những mục tiêu chất lượng phải phản ánh những tiêu chí chính được chấp nhận và được chỉ ra trong tài liệu yêu cầu của khách hàng[ ví dụ các tài liệu RFP]. Như vậy, những mục tiêu chất lượng như là đơn vị các thành công của các yêu cầu chất lượng của khách hàng [2] Kế hoạch đánh giá hoạt động Kế hoạh quản lý chất lượng phải cung cấp một danh sách đầy đủ tất cả các kế hoạch đánh giá hoạt động: đánh giá thiết kế [Design Reviews DRs], kiểm tra thiết kế, kiểm tra mã [code].., với những xác định sau cho từng hoạt động : Phạm vi đánh giá hoạt động Các loại hình đánh giá hoạt động Lập lịch đánh giá hoạt động [ được định nghĩa bởi độ ưu tiên và các hoạt động thành công của tiến trình dự án ] Các thủ tục cụ thể được áp dụng Ai chịu trách nhiệm thực hiện các hoạt động đánh giá lại? [3] Kế hoạch kiểm thử phần mềm Kế hoạch quản lý chất lượng phải cung cấp một danh sách đầy đủ kế hoạch kiểm thử phần mềm, với những thiết kế sau cho mỗi lần kiểm tra: Đơn vị, hệ thống tích hợp hay hoàn chỉnh để kiểm tra Các loại hình của hoạt động kiểm thử sẽ được thực hiện, bao gồm các đặc điểm kỹ thuật của các lần kiểm thử phần mềm trên máy tính được áp dụng Lịch lịch cho kế hoạch kiểm thử [ được định nghĩa bởi thứ tự ưu tiên của nó và những hoạt động thành công của tiến trình dự án ] Các thủ tục cụ thể được áp dụng Ai chịu trách nhiệm thực hiện kiểm tra 36

37 [4] Kế hoạch kiểm thử sự chấp nhận cho phần mềm phát triển bên ngoài Một danh sách đầy đủ của kế hoạch kiểm thử sự chấp nhận cho phần mềm phát triển bên ngoài phải được cung cấp trong kế hoạch quản lý chất lượng bao gồm các mục : [a] Phần mềm được mua [b] Phần mềm được phát triển bởi các nhà thầu phụ [c] Phần mềm được khách hàng cung cấp Kiểm thử sự chấp nhận cho phần mềm phát triển bên ngoài nên song song với việc kiểm thử phần mềm phát triển bên trong. [5] Quản lý cấu hình Kế hoạch quản lý chất lượng phải xác định các công cụ và thủ tục quản lý cấu hình, bao gồm cả các thủ tục kiểm soát thay đổi và phải áp dụng trong suốt dự án. Các thành phần quản lý chất lượng phần mềm được yêu cầu được liệt kê trong bảng sau: Các thành phần của quản lý chất lượng phần mềm 1. Danh sách các mục tiêu chất lượng 2. Đánh giá các hoạt động 3. Kiểm thử phần mềm 4. Kiểm thử sự chấp nhận phần mềm phát triển bên ngoài 5. Các công cụ và thủ tục quản lý cấu hình * Tài liệu quản lý chất lượng, sự phê duyệt và định dạng của nó Quản lý chất lượng có thể được chuẩn bị như một phần của kế hoạch phát triển hay như một tài liệu độc lập. Trong một số trường hợp, kế hoạch được chia thành một số tài liệu bởi hạng mục, như kế hoạch DR, kế hoạch kiểm thử, và kế hoạch kiểm tra sự chấp nhận phần mềm phát triển bên ngoài. Đánh giá và chấp thuận của kế hoạch quản lý chất lượng nên được tiến hành theo thủ tục chuẩn của tổ chức cho các kế hoạch như vậy. 37

38 Các kế hoạch phát triển và kế hoạch chất lượng cho các dự án nhỏ và các dự án nội bộ Việc các nhà lãnh đạo dự án cố gắng tránh khỏi những rắc rối trong quá trình chuẩn bị kế hoạch phát triển và quản lý chất lượng là điều tự nhiên. Điều này phản ánh xu hướng tránh việc làm việc quan liêu và kiểm soát chung chung mà khách hàng có thể dự tính thực hiện. Xu hướng này đặc biệt thường thấy trong 2 trường hợp : các dự án nhỏ và các dự án nội bộ. Sự chuẩn bị kế hoạch cho các dự án như vậy sẽ được thảo luận trong 2 phần sau. - Kế hoạch phát triển và quản lý chất lượng cho các dự án nhỏ " một dự án chỉ có thời hạn 40 ngày, có thể được thực hiện bởi một chuyên gia và hoàn thành trong 12 tuần, với 1 man-days có phải chuẩn bị lập kế hoạch quản lý chất lượng và phát triển toàn thể? " một dự án được thực hiện bởi 3 chuyên gia với tổng vốn là 30 man-days và hoàn thành trong 5 tuần, đòi hỏi phải lập kế hoạch toàn thể? Cần làm rõ rằng các thủ tục lập kế hoạch quản lý chất lượng và phát triển áp dụng cho các dự án lớn có thể sẽ không áp dụng được cho các dự án nhỏ. Các thủ tục đặc biệt là cần thiết. Các thủ tục này xác định cách giải quyết các dự án như trong các câu hỏi trên với việc chú trọng tới các kế hoạch : [1] trường hợp không cần lập kế hoạch quản lý chất lượng và phát triển. Ví dụ các dự án đòi hỏi khoảng 15 man-days [2] trường hợp việc chuẩn bị các kế hoạch phụ thuộc vào quyết định của lãnh đạo dự án. Ví dụ : một dự án đòi hỏi dưới 50 man-days mà không có rủi ro quan trọng đã được xác định. Trong trường hợp này có thể quyết định rằng việc lập kế hoạch là không cần thiết. Một ví dụ khác : một dự án nhỏ nhưng phức tạp cần được hoàn thành trong 30 ngày, trong đó sẽ có một hình phạt nghiêm trọng khi không hoàn thành đúng thời gian. Trong trường hợp này, lập kế hoạch là cần thiết để đối phó với những khó khăn của dự án. [3] Trường hợp việc lập kế hoạch phát triển và quản lý chất lượng là bắt buộc. Kế hoạch phát triển : " Các sản phẩm dự án, chỉ ra sự phân phối " Các điểm chuẩn của dự án " Các rủi ro trong việc phát triển " Ước lượng giá thành dự án Kế hoạch quản lý chất lượng : " Mục tiêu chất lượng Một số lợi ích của các dự án nhó được lập kế hoạch so với các dự án không được lập kế hoạch có thể được xác định, thậm chí cho các kế hoạch suy giảm : 38

39 [1] Sự hiểu biết đầy đủ và triệt để hơn các nhiệm vụ để có thể hoàn thành chúng [2] Trách nhiệm lớn hơn có thể được phân công [3] Dễ dàng hơn cho người quản lý và khách hàng trong việc chia sẻ quyền kiểm soát dự án và sớm phát hiện ra các sự chậm trễ không mong muốn [4] Hiểu biết tốt hơn về các yêu cầu và thời gian biểu được đặt ra giữa người phát triển và khách hàng - Kế hoạch phát triển và quản lý chất lượng đối với các dự án nội bộ Các dự án nội bộ là các dự án dự định dành cho các bộ phận khác trong tổ chức hoặc cho toàn bộ tổ chức, hoặc dùng các dự án này trong việc phát triển các gói phần mềm cho thị trường phần mềm. Nhìn chung, tất cả các dự án loại này sẽ không có sự tham gia của các khách hàng bên ngoài trong việc phát triển dự án. Các dự án nội bộ có quy mô vừa hoặc lớn. Tuy nhiên, ngay cả trong trường hợp này cũng có xu hướng tránh việc chuẩn bị các kế hoạch phát triển và quản lý chất lượng một cách đầy đủ. Ví dụ sau minh họa hậu quả tiêu cực của một dự án nội bộ không được lập kế hoạch : Bộ phận tiếp thị của công ty Toyware, một công ty sản xuất trò chơi vi tính mới, đã có kế hoạch tung ra thị trường Super Monster 2000 trò chơi vi tính mới của công ty trong mùa Giáng sinh sắp tới. Bộ phận phát triển phần mềm cho rằng việc xây dựng trò chơi nên được bắt đầu ngay lập tức để hoàn thành dự án đúng thời gian. Do đó, việc chuẩn bị một buổi thảo luận giữa bộ phần tiếp thị và bộ phận phát triển; và các kế hoạch phát triển và quản lý chất lượng không được xem là cần thiết. Bộ phận phát triển ước tính ngân sách khoảng $, và đã được chuyển giao. Theo lịch tiếp thị, kiểm thử hệ thống phải được hoàn thành trước 1 tháng 10 để bộ phận tiếp thị thực hiện các yêu cầu xúc tiến và quảng cáo chiến dịch trong mùa bán hàng của dịp Giáng sinh. Khi dự án tiến triển, nó có thể có một sự chậm trể. Vào cuối tháng 6, người ta nhận ra 3 tháng chậm trể là không thể tránh khỏi. Các hoạt động quảng cáo diễn ra trước 30.6 trở thành vô nghĩa. Cuối cùng, dự án hoán thành vào cuối tháng 2. Giá thành của dự án vượt đáng kể - thực tế chi phí vượt quá $ - nhưng thiệt hại lớn nhất là công ty mất cơ hội khai thác thị trường mùa Giáng sinh. Tuần trước, quản lý công ty quyết định sẽ tránh tất cả các dự án nội bộ phát triển trò chơi vi tính trong tương lai. Ví dụ này cho thấy rõ ràng là việc chuẩn bị các kế hoạch phát triển và quản lý chất lượng toàn bộ cho các dự án nội bộ - kể cả việc giám sát thường xuyên có thể rất có lợi cho việc thực hiện các dự án nội bộ. Bộ phận phát triển phần mềm có thể đạt được những thuận lợi sau đây với việc chuẩn bị kế hoạch : [1] Tránh vượt quá ngân sách. Điều này có tầm quan trọng đặc biệt trong việc đảm bảo lợi nhuận. 39

40 [2] Tránh thiệt hại cho các dự án khác do các chuyên gia tham gia vào dự án nội bộ bị chậm trễ nên chưa thể tham gia vào dự án khác. [3] Tránh trường hợp mất thị trường, đặc biệt liên quan đến danh tiếng của công ty, do các dự án nội bộ chậm trễ kéo theo các dự án bên ngoài phụ thuộc vào nó cũng bị trễ. Khách hàng nội bộ có thể có những thuận lợi sau : [1] Ít trễ hơn và ngân sách ít bị vượt quá hơn. [2] Kiểm soát tốt hơn quá trình phát triển, trong đó có việc xác định sự chậm trễ sớm hơn, từ đó có thể tìm cách giải quyết nguyên nhân của chúng. [3] Ít thiệt hại chậm trễ nội bộ hơn Tổ chức có thể có những lợi ích sau : [1] Giảm rủi ro mất thị trường do sản phẩm bị trễ [2] Giảm rủi ro bị kiện do hoàn thành các sản phẩm bị muộn, vì thế, giảm thiệt hại vì vi phạm hợp đồng [3] Giảm nguy cơ danh tiếng của công ty bị ảnh hưởng Giảm rủi ro phải bổ sung ngân sách 40

41 Chương 3. Các thành phần SQA trong vòng đời dự án 3.1. Tích hợp các hoạt động chất lượng trong vòng đời dự án Các mô hình phát triển phần mềm cung cấp một tập các khái niệm và các phương pháp luận cần thiết để xây dựng phần mềm. Thêm vào đó, mô hình phát triển bao gồm các định nghĩa của các hoạt động chính cần cho sự phát triển của dự án, cho các điểm mốc của của dự án. Người quản trị dự án sẽ xác định cách dự án thực hiện bằng việc xác định mô hình phát triển và áp dụng vào trong dự án. Hầu hết các hoạt động đảm bảo chất lượng được đặt trong cấu hình với các điểm mốc [milestones], trong đó yêu cầu xem xét lại các hoạt động phát triển sản phẩm đã được hoàn thiện trước đó. Do đó, những người đảm bảo chất lượng phần mềm nên hiểu biết về các mô hình kỹ nghệ phần mềm khác nhau để có thể chuẩn bị một kế hoạch chất lượng mà sẽ được tích hợp thành kế hoạch 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 Bốn mô hình của quy trình phát triển được bàn luận trong phần này là: Mô hình vòng đời phát triển phần mềm [SDLC]. Mô hình bản mẫu nhanh. Mô hình xoắn ốc. Mô hình hướng đối tượng. Mô hình vòng đời phát triển phần mềm [SDLC] là một mô hình truyền thống [hiện nay vẫn có thể áp dụng được]; nó cung cấp sự mô tả toàn diện nhất về quy trình phát triển phần mềm. Mô hình chỉ ra cần xây dựng những khối chính cho toàn bộ quá trình phát triển, được mô tả như là một chuỗi tuyến tính. Trong pha ban đầu của quy trình phát triển phần mềm, các tài liệu thiết kế sản phẩm được chuẩn bị, việc đánh giá phiên bản đầu tiên của chương trình máy tính chỉ diễn ra ở giai đoạn cuối của quy trình. Mô hình SDLC có thể đóng vai trò như một khung [framework] để biểu diễn các mô hình khác. Mô hình bản mẫu dựa trên sự thay thế của một hoặc nhiều pha trong mô hình SDLC bằng một quy trình đánh giá, các bản mẫu phần mềm được sử dụng cho quá trình giao tiếp giữa người phát triển, người sử dụng cuối và khách hàng. Các bản mẫu được đưa ra để người sử dụng đánh giá. Sau đó, người phát triển tiếp tục phát triển một bản mẫu nâng cao, bản mẫu này cũng phải được đưa ra để đánh giá. Quá trình đánh giá này tiếp tục cho đến khi dự án phần mềm được hoàn thiện hoặc bản mẫu phần mềm đã đạt được những gì mà pha đó yêu cầu. Trong trường hợp này, phần còn lại của quy trình phát triển có thể được thực thiện theo một phương pháp luận khác, chẳng hạn như theo mô hình SDLC truyền thống. 41

42 Mô hình xoắn ốc cung cấp một phương pháp luận nhằm đảm bảo hiệu quả về mặt hiệu năng của mỗi pha trong mô hình SDLC truyền thống. Mô hình này liên quan đến một quy trình lặp, tích hợp các yêu cầu thay đổi của khách hàng, phân tích và giải quyết các rủi ro, các hoạt động về mặt kỹ nghệ và kế hoạch cho phát triển phần mềm. Một trong những tương tác của mô hình xoắn ốc có thể là yêu cầu hoàn thiện ở mỗi pha của dự án trong mô hình SDLC. Mô hình hướng đối tượng kết hợp chặt chẽ việc sử dụng lại các phần mềm cỡ lớn bằng cách kết hợp các mô dun có thể sử dụng lại được thành các hệ thống phần mềm mới. Trong trường hợp không có mô dun phần mềm nào có thể sử dụng được [theo thuật ngữ đối tượng hoặc thành phần] sẵn có, người phát triển có thể thực hiện một quy trình bản mẫu hoặc quy trình SDLC để hoàn thành việc phát triển một hệ thống mới. - Mô hình vòng đời phát triển phần mềm [SDLC] SDLC là mô hình tuyến tính bắt đầu bằng việc định nghĩa các yêu cầu và kết thúc bằng sự vận hành của hệ thống và quá trình bảo trì. Thể hiện phổ biến nhất của SDLC là mô hình waterfall [thác nước]. Mô hình này được minh họa trong hình dưới đây: 42

43 Hình Mô hình thác nước Mô hình gồm có 7 pha: xác định yêu cầu, phân tích, thiết kế, coding, kiểm thử hệ thống, cài đặt và chuyển giao, vận hàng và bảo trì. Xác định yêu cầu: Mục đích của pha xác định yêu cầu là xác định các chức năng của hệ thống cần xây dựng, khách hàng phải đưa ra và xác định các quyết định của họ. Trong nhiều trường hợp hệ thống phần mềm là một phần của hệ thống lớn hơn. Thông tin về các phần khác của hệ thống được mở rộng sẽ giúp thiết lập sự cộng tác giữa đội dự án và các giao diện thành triển. phần phát 43

44 Phân tích: Nỗ lực chính ở đây là phân tích sự ẩn ý của những yêu cầuthành mô hình khởi tạo của hệ thống phần mềm. Thiết kế: Giai đoạn này bao gồm việc định nghĩa chi tiết đầu vào, đầu ra và các thủ tục xử lý, bao gồm cấu trúc dữ liệu, cơ sở dữ liệu, cấu trúc phần mềm,... Coding: Trong pha này, toàn bộ thiết kế được chuyển thành code. Việc coding bao gồm những hoạt động đảm bảo chất lượng phần mềm như inspection, unit test, và test tích hợp. Test hệ thống [System test]: Test hệ thống được thực hiện sau khi pha coding hoàn thiện. Mục đích chính của việc kiểm thử là càng tìm ra nhiều lỗi phần mềm càng tốt để đạt được mức độ chấp nhận của chất lượng phần mềm. Kiểm thử hệ thống được thực hiện bởi những người phát triển trước khi bàn giao cho khách hàng. Trong nhiều trường hợp, khách hàng thực hiện kiểm thử phần mềm một cách độc lập [còn gọi là test chấp nhận sản phầm] để đảm bảo rằng những người phát triển đã thỏa mãn tất cả những hứa hẹn và những phản ứng phần mềm bất ngờ hoặc lỗi có thể được thấy trước. Đây là điều khá phổ biến, khách hàng yêu cầu người phát triển để họ được tham gia vào trong quá trình kiểm thử hệ thống, một thủ tục đã tiết kiệm được về mặt thời gian và tài nguyên cho việc phân tách riêng biệt giữa test hệ thống và test chấp nhận. Cài đặt và chuyển giao: Sau khi hệ thống phần mềm được phê chuẩn, hệ thống được cài đặt để phục vụ như là một phần sụn, có nghĩa là, nó như là một phần của hệ thống thông tin, biểu diễn một thành phần cơ bản của hệ thống được mở rộng. Nếu hệ thống thông tin mới được xây dựng để thay thế hệ thống đang tồn tại, một quy trình chuyển giao phải được khởi tạo để đảm bảo rằng các hoạt động của tổ chức vẫn được tiếp tục mà không bị gián đoạn trong suốt pha chuyển giao. Vận hành và bảo trì: Vận hành phần mềm bắt đầu sau khi pha cài đặt và chuyển giao đã được xong. Xuyên suốt thời kì vận hành, thường ít nhất là một vài năm hoặc cho đến khi xuất hiện phần mềm mới, việc bảo trì là cần thiết. Việc bảo trì kết hợp ba kiểu dịch vụ: thích ứng sử dụng các đặc trưng của phần mềm đang tồn tại để thực hiện các yêu cầu mới; hoàn thiện thêm một số đặc trưng để cải thiện hiệu năng của phần mềm; sửa lỗi sửa các lỗi phần mềm được tìm thấy bởi người sử dụng trong quá trình vận hành. Số lượng các pha có thể thay thổi tùy theo đặc trưng của từng dự án. Trong các dự án phức tạp, các mô hình phần mềm cỡ lớn, một số pha có thể bị chia ra, do đó, số lượng các pha có thể lên đến tám, chín hoặc thậm chí là nhiều pha hơn nữa. Trong các dự án nhỏ, một số pha lại có thể bị gộp lại, giảm số lượng pha của SDLC xuống còn sáu, năm, thậm chí là chỉ còn bốn pha. 44

45 Ở cuối mỗi pha, các đầu ra được xem xét và đánh giá bởi người phát triển, và trong một số trường hợp cũng có thể là khách hàng tham gia. Các kết quả có thể của quá trình xem xét lại bao gồm: Sự phê chuẩn của các đầu ra ở pha đó và quy trình của pha tiếp theo Các yêu cầu chỉnh sửa, làm lại hoặc thay đổi các phần của pha cuối cùng; trong trường hợp đảm bảo tính chắc chắn, có thể trả về các pha gần nhất theo yêu cầu. Độ rộng của đường kết nối giữa các hình hộp chữ nhật trong hình minh họa phản ánh khả năng có những kết quả khác nhau. Do đó, hầu hết các quy trình được thực hiện như là một dòng tuyến tính. Tuy nhiên, cần chú ý rằng, mô hình nhấn mạnh các hoạt động phát triển trực tiếp và không chỉ ra sự tham gia của khách hàng trong quy trình phát triển. Mô hình Waterfall đã được đề xuất bởi Royce [1970] và sau đó đưa ra trong trong mô hình chung của nó được biết đến như là Boehm [1981]. Mô hình này cung cấp các nền tảng cho phần lớn các chuẩn đảm bảo chất lượng phần mềm đã được triển khai, chẳng hạn như chuẩn IEEE 1012, IEEE 12207,... - Mô hình bản mẫu Phương pháp bản mẫu: Cho phép phát triển nhanh và dễ dàng các bản mẫu phần mềm. Kết hợp với sự tham gia của khác hàng và người sử dụng trong quy trình phát triển để kiểm tra và đánh giá bản mẫu. Khi áp dụng phương pháp bản mẫu, những người sử dụng tương lai của hệ thống được yêu cầu bình luận các phiên bản của bản mẫu phần mềm khác nhau đã được chuẩn bị bởi người phát triển. Từ sự phản hồi của khách hàng và người sử dụng, người phát triển sẽ sửa bản mẫu cho phù hợp, cho đúng và thêm các phần vào hệ thống theo cách biểu diễn như là một phiên bản phần mềm tiếp theo để người sử dụng đánh giá. Quy trình này được lặp lại cho đến khi đạt được mục đích của bản mẫu hoặc toàn bộ hệ thống phần mềm được hoàn thiện. Ứng dụng điển hình của phương pháp luận bản mẫu được minh họa trong hình dưới đây: 45

46 Mô hình bản mẫu Phương pháp bản mẫu có thể được áp dụng trong sự kết hợp với các phương pháp luận khác hoặc có thể xem như là một phương pháp luận độc lập. Nói cách khác, sự mở rộng phương pháp bản mẫu có thể thay đổi, từ thay thế một pha SDLC [hoặc một pha trong phương pháp luận khác] đến bản mẫu hoàn thiện của toàn bộ hệ thống phần mềm. Phương pháp bản mẫu như là một phương pháp luận phát triển phần mềm đã được áp dụng có hiệu quả cho các loại dự án có kích thước từ nhỏ đến trung bình. Ưu điểm 46

47 cũng như thiếu sót chính của phương pháp bản mẫu so với SDLC được tổng kết lại trong bảng dưới đây: Ưu điểm: Quy trình phát triển ngắn. Tiết kiệm tài nguyên [man-days]. Phù hợp với các yêu cầu của khách hàng và giảm thiểu được rủi ro của dự án. Sự tiếp nhận [lĩnh hội] của người dùng về hệ thống mới nhanh hơn và dễ dàng hơn. Nhược điểm: - Mô hình xoắn ốc Giảm bớt khả năng mềm dẻo và thích nghi đối với những thay đổi và những bổ sung. Giảm sự chuẩn bị cho các trường hợp lỗi không mong đợi. Mô hình xoắn ốc, được xem xét bởi Boehm [1988, 1998], đưa ra một phương pháp luận cải thiện nhằm phục vụ cho các dự án cỡ lớn và phức tạp. Mô hình này được minh họa như hình dưới đây: 47

48 Mô hình xoắn ốc Theo mô hình xoắn ốc, sự phát triển phần mềm được hiểu như làm một quy trình lặp; tại mỗi lần lặp, các hoạt động sau được thực hiện: Lập kế hoạch. Phân tích và giải quyết rủi ro. Các hoạt động kỹ nghệ theo giai đoạn của dự án: thiết kế, coding, test, cài đặt và chuyển giao. Sự đánh giá của khách hàng bao gồm các bình luận, các thay đổi và các yêu cầu bổ sung,... 48

49 Một mô hình xoắn ốc tiên tiến, là mô hình xoắn ốc win - win. Mô hình xoắn ốc tiên tiến nhấn mạnh vào sự giao tiếp và thương lượng giữa khách hàng và người phát triển. Tên của mô hình ám chỉ thực tế rằng, bằng việc sử dụng mô hình này, khách hàng có thể nhận được hệ thống thỏa mãn nhất cái họ cần, và nhà phát triển có khả năng nhận được nhiều tiền và hoàn thành dự án đúng ngày. Điều này đạt được bằng việc nhấn mạnh vào sự tham gia của khách hàng và những hoạt động kĩ nghệ. Việc xem xét lại trong quá trình phát triển được điễn tả bằng hai đoạn đồ thị của xoắn ốc, với sự tham gia của khách hàng: đầu tiên là sự đánh giá của khách hàng, thứ hai là sự phản hồi và những yêu câu thay đổi của khách hàng. Tương tự như vậy, những hoạt động kĩ nghệ được miêu tả bằng hai đoạn trong hình xoắn ốc: đầu tiên là thiết kế, và thứ hai là xây dựng. Bằng sự đánh giá tiến trình dự án ở cuối mỗi đoạn, nhà phát triển có thể điều chỉnh tốt hơn toàn bộ quá trình phát triển. Mô hình xoắn ốc cải tiến Vì vậy, trong mô hình xoắn ốc cải tiến, sáu hoạt động sau phải thực hiện trong mỗi lần lặp: Những đặc tả yêu cầu, những phản hồi và những đòi hỏi thay đổi của khách hàng. 49

50 Những hoạt động lập kế hoạch của nhà phát triển. Phân tích và giải quyết những rủi ro của nhà phát triển. Những hoạt động thiết kế của nhà phát triển. Những hoạt động xây dựng của nhà phát triển, liên quan tới việc coding, test, cài đặt và release. Sự đánh giá của khách hàng. - Mô hình hướng đối tượng Mô hình hướng đối tượng khác với các mô hình khác bởi nó hướng tới việc sử dụng lại các thành phần phần mềm. Đặc trưng của phương pháp luận này là nó dễ dàng tích hợp các mô dun phần mềm đang tồn tại [được gọi là các đối tượng hoặc các thành phần] vào trong những hệ thống mới. Một thư viện thành phần phần mềm phục vụ cho mục đích này bằng việc cung cấp những thành phần phần mềm cho việc sử dụng lại. Vì thế, theo mô hình hướng đối tượng được chỉ ra trong hình 7.5, quy trình phát triển bắt đầu với chuỗi phân tích và thiết kế hướng đối tượng. Pha thiết kế được thực hiện bằng sự thu nhận các thành phần phù hợp từ thư viện phần mềm có thể sử dụng lại, khi các thành phần đó là ở trạng thái sẵn sàng trong thư viện. Sự phát triển thông thường - regular được thực hiện theo cách khác. Sao chép những thành phần phần mềm mới và sau đó đưa nó vào trong thư viện phần mềm cho mục đích sử dụng lại trong tương lai. Phương pháp này mong đợi sự lớn lên của kho thư viện thành phần phần mềm sẽ cho phép tăng việc sử dụng và chắc chắn sử dụng lại của phần mềm, một hướng sẽ cho phép mang lại ưu điểm lớn về mặt tài nguyên như sau: Kinh tế: Chi phí tích hợp thành phần phần mềm sử dụng lại ít hơn so với giá phát triển một phần mềm mới. Cải thiện chất lượng: Các thành phần phần mềm được sử dụng ít lỗi hơn là thành phần phần mềm mới xây dựng. Thời gian phát triển ngắn hơn: Việc tích hợp các thành phần phần mềm sử dụng lại làm giảm áp lực về mặt lịch biểu. Như vậy, ưu điểm của phương pháp luận hướng đối tượng so với phương pháp luận khác là sẽ làm tăng sự phát triển của kho lưu trữ phần mềm có thể sử dụng lại được. 50

51 Mô hình hướng đối tượng Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm Những hoạt động đảm bảo chất lượng là hướng quy trình, nói cách khác, có liên kết tới sự hoàn thành của một pha dự án, sự hoàn tất một mốc dự án, và nhiều hơn nữa. Những hoạt động đảm bảo chất lượng được tích hợp vào trong kế hoạch phát triển. Những người lên kế hoặc đảm bảo chất lượng cho một dự án cần xác định: Danh sách những hoạt động đảm bảo chất lượng cần thiết cho dự án. Với mỗi hoạt động đảm bảo chất lượng: " Thời gian. " 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. 51

52 " Những tài nguyên yêu cầu cho việc khắc phục những nhược sai sót và những thay đổi. Cường độ của những hoạt động đảm bảo chất lượng đã được lên kế hoạch được chỉ ra bởi số những hoạt động yêu cầu. Những yếu tố dự án và nhóm ảnh hưởng tới cường độ như sau: Yếu tố dự án: Độ lớn của dự án. Sự phức tạp và khó của kỹ thuật. Phạm vi của những thành phần sử dụng lại. Hậu quả nếu dự án bị lỗi. Yếu tố nhóm: Trình độ chuyên môn của những thành viên trong nhóm. Sự quen thuộc của nhóm với dự án và Kinh nghiệm của nhóm trong lĩnh vực. Tính sẵn sàng của những thành viên có thể trợ giúp nhóm. Sự hiểu biết giữa những thành viên trong nhóm, hay nói cách khác là số thành viên mới trong nhóm 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 những dạng Verification, Validation, và Qualification. Verification: quá trình đánh giá một hệ thống hay một thành phần để xác định xem những sản phẩm của một pha phát triển xác định có thỏa mãn những điểu kiện được đặt gia khi bắt đầu pha đó hay không. Validation: quá trình đánh giá một hệ thống hay một thành phần trong suốt hoặc khi kết thúc quá trình phát triển để xác định xem nó có thỏa mãn những yêu cầu đã đặc tả hay không. Qualification: quá trình xác định một hệ thống hoặc một thành phần có phù hợp với việc sử dụng hay không. Theo những định nghĩa của IEEE, verification kiểm tra tính nhất quán của sản phẩm đang phát triển với những sản phẩm đã được phát triển ở pha trước. Khi thực hiện, người thẩm tra đi sau quy trình phát triền và giả sử rằng tất cả những pha phát triển đằng 52

53 trước đã được hoàn thành một cách chính xác hoặc là như kế hoặc gốc hoặc là sau khi đã sửa chữa những sai sót được phát hiện. Validation miêu tả sự quan tâm của khách hàng, bằng cách thẩm tra những yêu cầu gốc của họ. Qualification 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 những chuẩn, kiểu, và cấu trúc chuyên nghiệp sẽ dễ dàng để bảo trì hơn những thành phần có code lạ. Người lên kế hoạch cần phải xác định xem những khía cạnh nào nên được sát hạnh trong mỗi hoạt động đảm bảo chất lượng phần mềm Rà soát Định nghĩa của IEEE [1990], quá trình rà soát là: Một quá trình hoặc lai. một cuộc họp mà trong đó một sản phẩm công việc hoặc một tập các sản phẩm công việc được đưa ra tới toàn thể cá nhân tham gia vào dự án, các giám đốc, người dùng, khách hàng và các bên quan tâm đến dự án nhằm lấy ý kiến phê bình và phê chuẩ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] - Ý kiến chuyên gia 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. Mục đích trực 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ế. Mục đích gián tiếp: - 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 53

54 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 tại bất cứ mốc phát triển nào yêu cầu sự hoàn thiện của tài liệu phân tích hay 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 - Những người tham gia - Sự chuẩn bị trước - Phiên DR - 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. Review Leader : - Có kiến thức và kinh nghiệm trong việc phát triển kiểu dự án được review - Có thâm niên ở mức độ bằng với hoặc cao hơn của project leader - Có mối quan hệ tốt với project leader và đội dự an - Có vị trí bên ngoài đội dự án Review team Phần lớn không thuộc đội dự án 54

55 Kích thước từ 3-5 người Đ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ế Danh sách bình luận 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 - Phiên DR Một cuộc họp phiên DR thông thường gồm có : 1. Trình diễn ngắn gọn về tài liệu thiết kế 2. Các bình luận của các thành viên review team 3. Kiểm tra và xác nhận thảo luận mỗi bình luận 4. 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 : - Phê duyệt đầy đủ - Phê duyệt từng phần - Từ chối phê duyệt - Các hoạt động hậu review Báo cáo Review Review leader thực hiện sau phiên review Bao gồm : o Tổng kết các thảo luận review o Quyết định về sự tiếp tục của dự án o Danh sách các hoạt động cần thiết phải làm o Tên thành viên chịu trách nhiệm theo sát việc hiệu chỉnh Tiến trình theo dõi 55

56 Review leader thực hiện 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: xét duyệt [inspection] 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 leader review. 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 Leader: Xác định những đoạn trong tài liệu thiết kế sẽ đuợc review Lựa chọn thành viên nhóm Lập lịch cho những phiên review Đưa tài liệu cho các thành viên trong đội trước phiên review Đội peer review: yêu cầu của inspection khá tỉ mỉ, còn walkthrough chỉ yêu cầu đơn giản. - Inspection: Đọc & liệt kê chú thích của họ 56

57 - Walkth-rough : Đọc các đoạn sẽ được review - Phiên peer review Inspection - Presenter đọc một đoạn tài liệu và thêm vào nếu cần thiết. - Những người liên quan hoặc đưa ra chú thích, hoặc phản ứng với những lời chú thích trong tài liệu. Walkthrough - Bắt đầu bằng sự trình bày ngắn của author [thường ko phải là presenter] hoặc tổng quan về dự án và những đoạn thiết kế sẽ được review. Scribe ghi lại vị trí, mô tả, kiểu, đặc điểm [sai sót, những phần thiếu, những phần thêm vào] của mỗi lỗi được chấp nhận. 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] Inspection: 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 của 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 57

58 - 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 đủ. Để rõ hơn những đặ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 sau đây: Thuộc tính Formal reviews design Inspections Walkthroughs Mục đích chính trực tiếp Mục đích chính gián tiếp Lãnh đạo việc xem xét lại - Phát hiện lỗi - Xác định rủi ro mới - Phê chuẩn tài liệu thiết kế - Phát hiện lỗi - Xác định sự sai lệch so với tiêu chuẩn Trao đổi kiến thức - Trao đổi kiến thức Người đứng đầu kỹ nghệ phần mềm hoặc là thành viên cao cấp - Hỗ trợ hoạt động sửa chữa Người điều hành chỉ đạo [ngang hàng] Phát hiện lỗi Trao đổi kiến thức Người tổ chức Người tham gia Các thành viên cấp cao và đại diện khách hàng Những ngang hàng người Những người ngang 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 thiết kế - Lập trình viên - Người kiểm thử - Người giám sát tiêu chuẩn - Chuyên gia bảo trì - Đại diện người dùng 58

59 Quá trình xem xét lại Họp tổng quan Không Có Có Sự chuẩn bị của những 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ó Có Có Cơ sở hạ tầng Đào tạo chính thức cho người tham gia Không Có Không Sử dụng checklist Không Có Không Lỗi liên quan đế thu thập dữ liệu Tài liệu hóa việc xem xét lại Không yêu cầu hình thức Báo cáo xem xét lại thiết kế hình thức Yêu cầu hình thức - Báo cáo đánh giá phiên thanh tra - Báo cáo tổng kết phiên thanh tra Không yêu cầu hình thức Báo cáo đánh giá phiên walkthrough 3.3. Đả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 chính của vòng đời phần mềm là giai đoạn hoạt động, thường kéo dài từ 5 đến 10 năm, mặc dù cũng có những trường hợp hoạt động kéo dài đến 15 năm và thậm chí là hơn thế nữa cũng không phải là hiếm. Vậy điều gì đã khiến cho gói phần mềm có thể đạt được tuổi thọ cao với nhóm người dùng mà đã hài lòng nó, trong khi gói phần mềm khác cũng phục vụ đối tượng đó lại bị hủy sớm? Yếu tố chính chịu trách nhiệm cho dịch vụ dài hay thành công là bảo trì chất lượng. Việc bảo trì phần mềm quan trọng 59

60 như thế nào có thể được giả định thông qua việc chú ý đến chủ đề được đưa ra trong chuẩn ISO [xem ISO[1977], phiên bản 4.19 và ISO/IEC [2001], phiên bản 7.5], IEEE [1998] và Oskarsson và Glass [1996]. Dưới đây là 3 thành phần của dịch vụ bảo trì và nó được xem như là bản chất của sự thành công: Bảo trì sửa lỗi: những dịch vụ hỗ trợ người dùng và sửa lỗi phần mềm. Bảo trì thích ứng: làm cho các gói phần mềm thích ứng với những yêu cầu mới của khách hàng và điều kiện môi trường thay đổi. Bảo trì cải thiện chất lượng: kết hợp [1] bảo trì hoàn thiện những chức năng mới được thêm vào phần mềm cũng như nâng cao hiệu suất, cùng với [2] bảo trì phòng ngừa những hoạt động cải thiện độ tin cậy và cơ sở hạ tầng hệ thống cho dễ dàng làm cho việc bảo trì trong tương lai hiệu quả hơn. Những dịch vụ hỗ trợ người dùng [ những trung tâm hỗ trợ người dùng ] trong bảo trì sửa lỗi có thể cần phải rõ ràng[clarification]. Những dịch vụ hỗ trợ giải quyết tất cả những khó khăn xuất hiện khi sử dụng hệ thống phần mềm của người dùng; những dịch vu sửa lỗi phần mềm thường được tích hợp trong dịch vụ này. Những khó khăn của người dùng có thể được gây ra bởi nguyên nhân sau: Lỗi code [thường được dùng với thuật ngữ thất bại phần mềm"-software failure ]. Lỗi viết tài liệu thủ công, giúp những màn ảnh hoặc các hình thức tài liệu hướng dẫn được chuẩn bị sẵn sàng cho người dùng. Trong trường hợp này, dịch vụ hỗ trợ có thể cung cấp cho người dùng với những chỉ dẫn đúng [mặc dù không có sự chính xác trong chính tài liệu phần mềm được thực hiện ]. Không đầy đủ, mơ hồ hoặc tài liệu không chính xác. Thiếu kiến thức về hệ thống phần mềm của người dùng hoặc thất bại của họ khi sử dụng tài liệu được cung cấp. Trong những trường hợp này không có xét đến thất bại hệ thống phần mềm. Ba nguyên nhân đầu tiên ở trên được xem như là những thất bại của hệ thống phần mềm. Thêm vào đó, sự tích hợp của những dịch vụ hỗ trợ người dùng và những dịch vụ hiệu chỉnh phần mềm nói chung là đã được hoàn thành trong sự kết hợp gần gũi, với nhiều thông tin chia sẻ. Những thành phần khác của dịch vụ bảo trì cải thiện chất lượng và bảo trì thích ứng khuynh hướng không được bắt đầu bởi những dịch vụ hỗ trợ người dùng. Trong hầu hết các trường hợp, những công việc cải thiện chức năng và khả năng thích ứng sẽ trình bày những đặc tính của một dự án nhỏ hoặc lớn, điều đó phụ thuộc vào những mong muốn của khách hàng. Trong trường hợp này, những công việc trên có thể được thực thi như là một phần của quá trình phát triển phấn mềm. Khi xem xét ở trên, việc bao gồm những dịch vụ hỗ trợ người dùng trong những hoạt động bảo trì sửa đổi là hợp lý. 60

61 Nói chung, chúng ta có thể nói rằng việc bảo trì sửa lỗi bảo đảm những người dùng hiện thời có thể thao tác hệ thống như đã được vạch rõ, bảo trì thích ứng có thể mở rộng cho những đối tượng người dùng, và bảo trì cải thiện chất lượng đưa ra giai đoạn dịch vụ của gói. Như đã đề cập trong mục trước, việc kết hợp 3 thành phần bảo trì phần mềm chiếm hơn 60% tổng số tài nguyên thiết kế và lập trình dành cho hệ thống phần mềm trong suốt vòng đời của nó [Pressman, 2000]. Những ước lượng khác chia sẻ những tài nguyên bảo trì kéo dài từ trên 50% [Lientz và Swanson, 1980] đến % tổng số những tài nguyên phát triển dự án. 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ì cao Nhiều người cho rằng chất lượng của gói phần mềm được bảo trì có lẽ là cơ sở quan trọng nhất nằm dưới chất lượng của những dịch vụ bảo trì. Nhưng cũng có những nhà phê bình khác cho rằng đó là chính sách bảo trì. Dưới đây là những thảo luận về chủ đề này 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 được bảo trì rõ ràng bắt nguồn từ sự thành thạo và những nỗ lực của nhóm phát triển cũng như những hoạt động SQA được thực hiện xuyên suốt quá trình phát triển. Nếu chất lượng của gói phần mềm là nghèo nàn thì cũng dẫn đến việc bảo trì nghèo nàn hoặc không có hiệu quả. Khi mà hiểu sâu sắc cơ sở này, chúng ta sẽ lựa chọn việc nhấn mạnh 7 trong 11 nhân tố đảm bảo chất lượng ban đầu mà có tác động trực tiếp trong bảo trì phần mềm. Đặc biệt là, chúng ta sẽ thảo luận về 2 trong 5 nhân tố thao tác sản phẩm, 3 nhân tố xem xét lại sản phẩm và 2 trong 3 nhân tố chuyển giao sản phẩm. 61

62 Hai nhân tố thao tác sản phẩm: Sự chính xác [Correctness] bao gồm: Sự chính xác của đầu ra: Việc hoàn thành những đầu ra được chỉ rõ[nói cách khác là không có đầu ra mà đã được chỉ ra trước đó bị thiếu], sự đúng đắn của những đầu ra [những đầu ra của hệ thống được xử lý một cách chính xác], đầu ra hợp thời [thông tin được xử lý luôn được cập nhật như đã chỉ rõ] và đầu ra có tính sẵn sàng [Những lần tương tác không vượt những giá trị cực đại xác định, đặc biệt là những ứng dụng trực tuyến và thời gian thực]. Sự chính xác của tài liệu hướng dẫn: Chất lượng của tài liệu hướng dẫn: tính đầy đủ, sự đúng đắn, kiểu và cấu trúc tài liệu. Những hình thức tài liệu bao gồm bản sao trên giấy và những file máy tính được in ấn thông thường cũng như những file trợ giúp điện tử - trong khi phạm vi của nó chứa đựng những tài liệu cài đặt, tài liệu hướng dẫn người dùng và tài liệu của người lập trình viên. Viết mã đúng quy cách: phù hợp với những hướng dẫn mã, đặc biệt là những hạn chế và sự phức tạp trong mã biến đổi cũng như xác định kiểu viết mã chuẩn. Độ tin cậy. Tần số của những thất bại của hệ thống cũng như những lần phục hồi. Ba nhân tố xem xét lại sản phẩm: Sự bảo trì: Những yêu cầu này được thực hiện đầu tiên và tốt nhất bằng cách làm theo cấu trúc phần mềm và những yêu cầu kiểu cũng như là theo cài đặt những yêu cầu trong tài liệu của lập trình viên. Tính linh động: Đạt được thông qua việc thiết kế, lập kế hoạch thích hợp và những đặc tính cung cấp không gian ứng dụng lớn hơn nhu cầu của người dùng hiện tại. Có thể test được: Có thể test bao gồm tính sẵn sàng của những chuẩn đoán hệ thống được đưa ra bởi người dùng cũng như những chuẩn đoán thất bại được áp dụng bởi trung tâm hỗ trợ hoặc những nhân viên bảo trì tại vị trí người dùng. Cuối cùng là 2 nhân tố chuyển phát sản phẩm: 62

63 [1] Tính khả chuyển: Các ứng dụng tiềm tàng của phần mềm trong môi trường phần cứng và hệ điều hành khác nhau, nó gồm những hoạt động mà cho phép thực hiện những ứng dụng đó. [2] Thao tác giữa các phần: Khả năng của các gói giao tiếp với các gói hoặc thiết bị tính toán khác. Bằng việc cung câp khả năng đáp ứng những chuẩn về giao diện và áp dụng những giao diện đó một cách phù hợp kết hợp với những hướng dẫn của thiết bị sản xuất và phần mềm, thao tác giữa các phần có thể đạt được ở mức cao Cơ sở 2: Chính sách bảo trì Những thành phần của chính sách bảo trì chính ảnh hưởng đến sự thành công của việc bảo trì phần mềm là sự phát triển các phiên bản và thay đổi chính sách để được áp dụng trong suốt vòng đời phần mềm. Chính sách phát triển phần mềm Chính sách này có quan hệ mật thiết với câu hỏi có bao nhiêu phiên bản phần mềm được vận hành cùng một lúc. Rõ ràng rằng, đây không phải là vấn đề dịch vụ của một tổ chức về phần mềm được đặt hàng mà vấn đề chính ở đây là số lượng các phiên bản hay chính là giá thành [COSTs]của những gói phần mềm được lên kế hoạch để phục vụ cho nhiều khách hàng khác nhau. Chính sách phát triển phiên bản sau này có thể được thực hiện dưới dạng tuần tự hoặc cây. Khi áp dụng chính sách tuần tự, chỉ một phiên bản được tạo ra sẵn cho toàn bộ khách hàng. Phiên bản này gồm số lượng lớn những ứng dụng mà biểu lộ sự dư thừa cao, một thuộc tính mà cho phép phần mềm phục vụ tất cả những mong muốn của khách hàng. Phần mềm phải được xem lại một cách định kỳ nhưng một khi một phiên bản mới được hoàn thành, nó sẽ thay thế phiên bản đang được sử dụng hiện thời bởi toàn bộ đối tượng người dùng. Khi áp dụng chính sách phiên bản cây, nhóm bảo trì phần mềm hỗ trợ những nỗ lực marketing [quảng cáo/tiếp thị]bằng việc phát triển một phiên bản chuyên dụng, nhằm tới những nhóm khách hàng hay khách hàng chính một khi nó được yêu cầu. Một phiên bản mới được bắt đầu bằng việc thêm những ứng dụng đặc biệt hoặc bỏ qua những ứng dụng, phụ thuộc vào những gì liên quan đến nhu cầu của khách hàng. Những phiên bản này thay đổi theo sự phức tạp và mức của ứng dụng những ứng dụng hướng công nghiệp được hướng tới,vv Nếu chính sách này được chấp nhận, gói phần mềm có thể tiến triển thành một gói đa phiên bản sau vài năm của dịch vụ, có nghĩa rằng giống như một cái cây, với vài nhánh chính và nhiều nhánh phụ, từng phần nhánh đại diện cho một 63

64 phiên bản đã được duyệt lại một cách chuyên dụng. Trái với phiên bản phần mềm dạng tuần tự, việc bảo trì và quản lý của phiên bản phần mềm dạng cây phức tạp và tốn thời gian hơn nhiều. Xem xét sự thiếu xót này, những tổ chức phát triển phần mềm cố gắng áp dụng chính sách phiên bản dạng cây một cách giới hạn, chỉ cho phép một số lượng nhỏ những phiên bản phần mềm được phát triển. Chính sách thay đổi Chính sách thay đổi đề cập đển phương thức để kiểm tra mỗi yêu cầu thay đổi và tiêu chuẩn sử dụng cho những phương pháp đó. Một chính sách là rõ ràng nếu nó được thực thi bởi CCB[The Change Control Board _ Ban điều khiển thay đổi ] hoặc những người được ủy quyền để phê duyệt những thay đổi đó. Chính sách cân bằng đòi hỏi có một cuộc kiểm tra tỉ mỉ những yêu cầu thay đổi, điều này là rất phù hợp vì như vậy nó cho phép nhân viên tập trung vào những thay đổi quan trọng và có ích nhờ thế chúng ta mới có thể thực thi công việc trong thời gian hợp lý và theo những 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ư những thành phần SQA tiền dự án, những hoạt động SQA trước bảo trì cần được hoàn thành để khởi tạo các dịch vụ bảo trì cần thiết cũng rất quan trọng. Nó bao gồm thứ tự các bước sau: Xem xét lại hợp đồng bảo trì Xây dựng kế hoạch bảo trì Xem xét lại hợp đồng bảo trì Khi xem xét hợp đồng bảo trì, quan điểm mở rộng nên được khái quát. Đặc biệt, những quyết định được yêu cầu về các loại hình dịch vụ cần được ký kết trong hợp đồng. Những quyết định này phụ thuộc vào các loại hình dịch vụ khách hàng: dành cho khách hàng mà có gói custom-made được phát triển; dành cho khách hàng mà mua gói phần mềm COST và những khách hàng bên trong. Vì vậy, trước khi bắt đầu cung cấp những dịch vụ bảo trì phần mềm tới từng nhóm khách hàng trên thì hợp đồng bảo trì tương ứng phải được hoàn thành để nó đánh giá tổng số những trách nhiệm bảo trì theo những điều kiện liên quan. Giả định sự thực thi Những dịch vụ bảo trì tới khách hàng bên trong thường không có hợp đồng. Trong một số trường hợp cụ thể, một vài dịch vụ được cung cấp trong quá trình thực hiện mà không có sự xác định rõ ràng cho những dịch vụ đó. Trong những trường hợp như vậy thì sự không hài lòng dễ xảy ra trong cả 2 phía: những khách hàng bên trong cảm thấy rằng họ mong muốn được hỏi 64

65 ý kiến một cách có thiện ý thay vì nhận những dịch vụ một cách đều đặn mà họ không mong chờ, bên cạnh đó thì nhóm phát triển lại luôn yêu cầu thực thi việc bảo trì như là một việc bắt buộc một khi họ đã làm việc trong một dự án khác. Để tránh tình trạng căng thẳng, một hợp đồng dịch vụ bên trong nên được viết. Trong tài liệu này, những dịch vụ này được cung cấp bởi nhóm bảo trì bên trong tới những khách hàng bên trong được xác định một cách rõ ràng. Với việc bỏ qua hầu hết những hiểu sai liên quan đến những dịch vụ ảo, hợp đồng này có thể đáp ứng một cách cơ bản những bảo trì thỏa đáng tới những khách hàng bên trong. Những hoạt động xem xét lại hợp đồng bảo trì bao gồm việc nhìn lại những bản nháp đề xuất cũng như là nhìn lại những bản hợp đồng nháp. Thực tế, việc nhìn lại mục tiêu và sự thực thi bản hợp đồng bảo trì là đi theo từng dòng trong việc xem xét lại bản hợp đồng tiền dự án. mềm: 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 Sự rõ ràng trong yêu cầu của khách hàng Những vấn đề sau đây đặc biệt được quan tâm: Loại dịch vụ bảo trì sửa đổi được yêu cầu: Danh sách những dịch vụ từ xa và những dịch vụ tại chỗ được cung cấp, giờ phục vụ, thời gian phản hồi,. Số lượng người sử dụng và kiểu ứng dụng được dùng. Những người dùng địa phương, ở khoảng cách xa [hoặc qua đại dương] và các kiểu dịch dụ được cài đặt tại mỗi nơi đó. Cung cấp bảo trì cải thiện chức năng, khả năng thích ứng và thủ tục cho những yêu cầu của dịch vụ cũng như đề xuất và phê duyệt việc thực thi cho những dịch vụ này. 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ì Xem xét những suy xét cụ thể dưới đây để đưa ra lựa chọn phù hợp: Những hợp đồng con cho những site [địa điểm] hoặc kiểu dịch vụ Việc thực thi một vài dịch vụ thông qua khách hàng cùng với sự hỗ trợ từ nhóm bảo trì của nhà cung cấp. Nhìn lại sự ước lượng về tài nguyên bảo trì được yêu cầu Đầu tiên, những ước lượng nên được kiểm tra lại trên cơ sở của những dịch vụ được yêu cầu, sắp xếp theo đề xuất của nhóm. Sau đó, dựa vào năng lực của công ty để xem có đáp ứng được những khía cạnh chuyên môn cũng như là tính sẵn sàng của nhóm bảo trì đã phân tích hay không. 65

66 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. Việc nhìn lại này đề cập tới việc định danh lại những dịch vụ được cung cấp bởi mỗi người tham gia, số tiền trả cho những hợp đồng con, đảm bảo chất lượng và những thủ tục tiếp theo được đáp ứng. Xem xét lại những ước lượng về giá thành bảo trì Những ước lượng này nên được nhìn lại dựa trên cơ sở của những tài nguyên được yêu cầu Lập kế hoạch bảo trì Lập kế hoạch bảo trì phải được chuẩn bị cho tất cả các khách hàng trong và ngoài. Những kế hoạch này nên cung cấp framework trong việc tổ chức những điều khoản bảo trì. Lập kế hoạch đó bao gồm những bước sau: 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. Mô tả tổ chức của nhóm bảo trì Kế hoạch tổ chức nhóm bảo trì tập trung vào những yêu cầu về nhân sự. Điều đó có thể được xem xét cẩn thận theo những tiêu chuẩn sau: 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 Danh sách điều kiện thuận lợi cho bảo trì 66

67 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ì với thiết bị phần cứng và phần mềm đã được cài đặt để cung cấp những dịch vụ hỗ trợ cho người dùng và sửa đổi 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: [1] Tài liệu phần mềm, bao gồm tài liệu phát triển. [2] Những hợp đồng dịch vụ [3] Cấu hình phần mềm cho mỗi khách hàng và phiên bản của những gói phẩn mềm được cài đặt tại mỗi địa điểm và được cung cấp bởi nhà quản lý cấu hình. [4] Những thông tin bảo trì lịch sử được ghi lại cho mỗi người dùng và khách hàng. Danh sách những rủi ro dịch vụ bảo trì được xác định Rủi ro dịch vụ bảo trì liên quan đến hoàn cảnh mà thất bại xảy ra để cung cấp bảo trì tương ứng được dự đoán trước. Những rủi ro này bao gồm: 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ự hiểu biết và trình độ chuyên môn không tương xứng với từng phần của các gói phần mềm liên quan để thực thi những dịch vụ hỗ trợ người dùng và/hoặc những công việc bảo trì sửa đổi. 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. 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 những thủ tục được yêu cầu để cập đến những tiến trình được thực thi bởi những nhóm bảo trì sửa đổi và trung tâm hỗ trợ người dùng. Những thủ tục này giải quyết: 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ì. Ngân sách bảo trì phần mềm Những ước lượng được sử dụ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 yêu cầu và sự đầu tư vốn cần để tạo ra những điều kiện, những nhu cầu của nhóm và tác vụ khác. Họ phải được chuẩn bị mỗi khi nhân sự, trình độ chuyên môn và các thủ tục được xác định. Những ước lượng cho việc bảo trì cải thiện chất lượng và khả năng thích ứng được chuẩn bị theo sự mong đợi, và theo sự thay đổi cũng như là cải thiện khi chúng được thực hiện. 67

68 Các công cụ đảm bảo chất lượng bảo trì phần mềm Sự đa dạng của các công cụ đảm bảo chất lượng phần mềm được sử dụng trong các chu kỳ thực hiện của vòng đời phần mềm. Bản chất riêng biệt của mỗi thành phần bảo trì phần mề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 cần phải sử dụng cho mỗi loại. Hơn nữa, chu kỳ thực hiện của phần mềm điển hình thì mở rộng việc sử dụng các công cụ SQA cơ sở và công cụ giám sát việc quản lý. Ý tưởng về việc đưa SQA vào pha bảo trì được Perry đưa ra [1995]. Trong 1 nghiên cứu ông thực hiện vào tháng 11 năm 1994, các bên tham gia được thông báo rằng: dựa trên kinh nghiệm của họ thì 31% kế hoạch bảo trì của họ đã được thực hiện để đảm bảo chất lượng. 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 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 và [b] sửa chữa phần mềm [sửa lỗi]. Các dịch vụ hỗ trợ người sử dụng giải quyết các trường hợp lỗi về mã phần mềm và lỗi tài liệu, tài liệu không hoàn thành hoặc mập mờ. Chúng có thể chứa những câu lệnh mà người sử dụng không đủ kiến thức về phần mềm hoặc thất bại trong việc sử dụng tài liệu có sẵn. Các dịch vụ sửa chữa phần mềm gỡ lỗi và sửa tài liệu được sử dụng trong trường hợp lỗi phần mềm [failure], và được cung cấp trong suốt chu kỳ khởi tạo của việc thực hiện [mặc dù sự nỗ lực này được đầu tư vào việc testing] và tiếp tục được yêu cầu mặc dù không thường xuyên lắm. Dù hai kiểu dịch vụ khác nhau nhưng tập các công cụ đảm bảo chất lượng đều tập trung vào cùng một mục đích là đảm bảo chất lượng dịch vụ. Trong nhiều trường hợp cùng một đội có thể thực hiện cả hai kiểu bảo trì sửa lỗi. Thêm vào các công cụ SQA giám sát việc quản lý và cơ sở hạ tầng [được thảo luận ở phần sau của chương] thì hầu hết các công việc sửa lỗi yêu cầu sử dụng các công cụ SQA cho vòng đời nhỏ, mainly mini-testing [test những phần nhỏ quan trọng]. Thủ tục mini-testing được yêu cầu cho việc xử lý các tác vụ về lỗi đường dẫn [repair patch] [small - scale], nó được đặc trưng bởi số lượng nhỏ dòng lệnh thay đổi cùng nhau để hoàn thành việc sửa lỗi nhanh chóng. Những vấn đề liên quan đến sửa chữa trì hoãn giống như một abridged-mini-form của testing thường được sử dụng. Tuy nhiên, sử dụng 68

69 những công cụ mini testing vẫn cần được thực hiện để tránh những trường hợp không thể test được. Để đảm bảo chất lượng của mini testing, những chỉ dẫn sau nên được giữ vững: - Testing được thực hiện bởi những tester chất lượng, không phải bởi người lập trình thực hiện sửa chữa - Tài liệu thủ tục test [dài nhất là 2-3 trang] nên được chuẩn bị. Tài liệu bao gồm một bản mô tả về những ảnh hưởng biết trước được của việc sửa chữa, phạm vi sửa lỗi và một danh sách các test case được thực hiện. Tài liệu thủ tục trước test, tương tự như tài liệu thủ tục testing cũng nên được chuẩn bị để thực hiện test việc sửa lỗi được phát hiện trong test trước. - Một bản ghi test đầy đủ viết về các lỗi phát hiện được dưới dạng tài liệu trong mỗi giai đoạn test và re-test nên được hoàn thành. - Nhóm test chính xem lại tài liệu test về phạm vi sửa lỗi, tính đúng đắn của các test case và các kết quả test. - Việc sửa chữa được cho là simple và trivial, đặc biệt đối với việc thực hiện tại site của khách hàng, mini-testing có thể được tránh đi. Các dịch vụ bảo trì hợp đồng con, đặc biệt là các dịch vụ hỗ trợ người sử dụng đã trở nên khá phổ biến bất cứ khi nào có quá nhiều vẫn đề hoặc không kinh tế cho nhà thầu bảo trì cung cấp các dịch vụ đó một cách trực tiếp. Công cụ chính để đảm bảo chất lượng của các dịch vụ bảo trì của nhà thầu phụ và mở đường cho các quan hệ suôn sẻ là hợp đồng contractor-subcontractor. Công cụ SQA được tích hợp vào hợp đồng nhằm mục đích: [i] [ii] [iii] [iv] [v] Các thủ tục xử lý phân loại cụ thể các cuộc gọi bảo trì. Tài liệu đầy đủ về các thủ tục dịch vụ. 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. 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. 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 Các công cụ SQA cho bảo trì cải thiện chức năng Do sự giống nhau của việc bảo trì cải thiện chức năng và dự án phát triển phần mềm, các công cụ vòng đời dự án được áp dụng cho bảo trì cải thiện chức năng. Những 69

70 công cụ này cũng được thực thi cho bảo trì thích ứng phạm vi rộng [large scale adaptive maintenance]. Các công cụ SQA mở rộng được thực thi cho bảo trì cải thiện chức năng là các công cụ điều khiển quản lý và cơ sở hạ tầng, được thảo luận thêm ở phần sau Các thành phần cơ sở hạ tầng SQA 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 à các thành phần quan trọng của bảo trì phần mềm. Sự cân đối của mảng các công cụ SQA cơ sở là bản chất và được thực thi trong suốt vòng đời của hệ thống phần mềm. Hơn nữa, sự giống nhau của các tiến trình cải thiện chức năng phần mềm và phát triển phần mềm cho phép các tiến trình dùng chung các công cụ SQA cơ sở và chỉ có thay đổi nhỏ. Các công cụ cơ sở chuyên dụng được yêu cầu cho các hoạt động bảo trì sửa lỗi do các đặc trưng đặc biệt của các hoạt động này. Các hoạt động bảo trì thích ứng được phục vụ bởi các công cụ SQA cơ sở, theo các đặc trưng của nó. Các công cụ được áp dụng thường xuyên nhất là các công cụ SQA cải thiện chức năng, được theo bởi các công cụ SQA bảo trì sửa lỗi. Thực tế, sự đóng góp của các công cụ SQA cơ sở cho việc bảo trì không bắt đầu tại thời điểm ban đầu của các tiến trình bảo trì. Rõ ràng là việc áp dụng thích hợp các công cụ SQA cơ sở bởi đội phát triển phần mềm đóng góp căn bản vào hiệu quà và hiệu năng các hoạt động của đội bảo trì. Nói cách khác, những công cụ này góp phần vào việc bảo trì đảm bảo chất lượng theo 2 cách: đâu tiên, bằng cách hỗ trợ đội phát triển phần mềm khi tạo ra phần mềm chất lượng cao, và thứ hai, bằng cách hỗ trợ đội bảo trì đáp ứng việc bảo trì của sản phẩm phần mềm giống nhau. Các công cụ SQA cơ sở chuyên dụng được yêu cầu cho các tiến trình bảo trì phần mềm, đặc biệt là bảo trì sửa lỗi, thể hiện các đặc trưng đặc biệt. Ở đây chúng ta tập trung vào các công cụ SQA cơ sở chuyên dụng của các lớp sau: Các thủ tục bảo trì và các chỉ dẫn làm việc Hỗ trợ các thiết bị 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 Quản lý cấu hình Viết tài liệu và điều khiển bản ghi chất lượng Các thủ tục bảo trì và chỉ dẫn làm việc Hầu hết các thủ tục bảo trì và các chỉ dẫn làm việc chuyên dụng được áp dụng cho các hoạt động bảo trì sửa lỗi và hỗ trợ người sử dụng, ví dụ: 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 70

71 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. Cc thiết bị hỗ trợ chất lượng Bảo trì được mong đợi để phát triển các thiết bị chuyên dụng hỗ trợ các hoạt động sửa lỗi phần mềm và hỗ trợ người dùng: templates[khuôn mẫu], checklists [danh sách kiểm tra] và những cái tương tự thế. Các thiết bị có thể bao gồm: 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ỏ. Đà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. Việc đào tạo các chuyên gia bảo trì sửa lỗi được thúc đẩy bởi yêu cầu hỗ trợ các dịch vụ cụ thể trong hợp đồng bảo trì. Do vậy, kế hoạch đào tạo nên cung cấp các giải pháp cho các yêu cầu nhân sự trong suốt các chu kỳ trọng tải cao nhất và các yêu cầu của tổ chức để thay thế nhân sự bị sa thải. Trong nhiều trường hợp, việc đào tạo các nhân viên bảo trì dự trữ là không đủ, phải đào tạo thêm hệ thống riêng biệt. Nói cách khác, chương trình đào tạo nghiêm ngặt được yêu cầu để cho phép tổ chức xác định phạm vi với mức độ ràng buộc của các dịch vụ riêng biệt cho các chu kỳ trọng tải cao và trong trường hợp thay đổi nhân viên bảo trì hoặc bất kỳ lý do nào khác. Yêu cầu cấp chứng chỉ cho các nhân viên sửa lỗi phần mềm và hỗ trợ người dùng là gốc rễ trong các đặc trưng của các dịch vụ này. Sự quan tâm đặc biệt nên dành cho việc cấp chứng chỉ cho các nhân viên sửa lỗi phần mềm, người mà thường xuyên thực hiện công việc của họ dưới áp lực về thời gian lớn, làm việc 1 mình, và trong nhiều trường hợp làm việc tại site của khác hàng, nơi mà sự hỗ trợ chuyên gia từ team leader hoặc những người khác bị giới hạn. 71

72 Các hoạt động ngăn ngừa và sửa lỗi Pha hoạt động của vòng đời phần mềm tạo ra thông tin có giá trị cao: các bản ghi lỗi phần mềm, sửa chữa các lỗi đó cũng như bản ghi các yêu cầu hỗ trợ khách hàng có thể dẫn tới các hoạt động ngăn ngừa và sửa lỗi do đó góp phần cải thiện hệ thống phần mềm đã có và phần mềm mới. Để các tiến trình hoạt động hiệu quả, cần có các tiến trình thích hợp cho việc biểu diễn thông tin thu thập được, xem lại và phân tích những phát hiện, và đưa ra những gợi ý cho việc cải thiện các tiến trình bảo trì và phát triển liên quan. Những hoạt động SQA này được chỉ dẫn và điều khiển bởi ủy ban nội bộ - CAB [Corrective Action Board], được sáng lập trong tổ chức phát triển phần mềm chính. Những vấn đề điển hình ban xúc tiến cần xem lại gồm: Quản lý cấu hình Những thay đổi về nội dung và tính thường xuyên của khách hang yêu cầu về các dịch vụ hỗi trợ người dùng Tăng thời gian trung bình được đầu tư để tuân theo yêu cầu hỗ trợ của khách hàng Tăng thời gian trung bình được đầu tư đê sửa chữa các lỗi phần mềm của khách hàng Tăng phần trăm các lỗi hiệu chỉnh phần mềm. Nhóm bảo trì đưa ra hầu hết tập các phụ thuộc vào quản lý cấu hình. Sự phụ thuộc này là kết quả của các mối quan hệ dựa trên kinh nghiệm với các gói phần mềm dịch vụ qua nhiều năm, trong suốt các phiên bản mới được thêm vào, phiên bản cũ bị thay thế và nhiều sự cài đặt mới và các thay đổi phần mềm được thực hiện. 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 [group replacement] 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 ttheo 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ó. # Sự đóng góp vào chất lượng phần mềm được thể hiện là lỗi ít hơn trong các thử nghiệm hiệu chỉnh lỗi và giảm bớt được tài nguyên đầu tư vào sửa lỗi. 72

73 2. Group replacement [Thay thế nhóm]: Thuật ngữ group trong SQA đề cập đến tất cả khách hàng có cùng phiên bản phần mềm được cài đặt tại site của họ. Do vậy, group replacement chỉ rõ rằng tất cả khách hàng sử dụng phiên bản sẽ được nhân phiên bản mới được phát triển hoặc cập nhật tại cùng 1 thời gian. Quản lý cấu hình hỗ trợ cho vấn đề thay thế nhóm dựa trên thông tin về các thành viên của nhóm khách hàng Đưa ra quyết định về tính thích hợp của việc thực hiện thay thế nhóm dựa trên quy mô của việc thay thế và kiểu hợp đồng đã ký với khách hàng. Lên kế hoạch thay thế nhóm, phân phối tài nguyên và xác định thời gian. # Sự đóng góp vào chất lượng phần mềm thể hiển ở việc thay thế phiên bản phần mềm hiện thời bởi những phiên bản đã được cải thiện mà giảm lỗi phần mềm, yêu cầu ít sự hỗ trợ. Cải thiện chất lượng cũng góp phần bảo trì phần mềm hiệu quả, yêu cầu ít tài nguyên cho bảo trì sửa lỗi. Tài liệu bảo trì và bản ghi chất lượng Những yêu cầu cụ thể cho tài liệu và bản ghi chất lượng có quan hệ chặt chẽ nhất với các hoạt động sửa lỗi phần mềm và hỗ trợ người sử dụng. Tài liệu và bản ghi chất lượng được chuẩn bị để: Cung cấp dữ liệu cần thiết cho các hoạt động ngăn ngừa và sửa lỗi. Hỗ trợ việc xử lý các yêu cầu hỗ trợ người dùng và các báo cáo lỗi khách hàng trong tương lai. Cung cấp bằng chứng để đáp ứng những yêu sách từ phía khách hàng trong tương lai. Những yêu cầu tài liệu được liệt kê trong các thủ tục bảo trì khác nhau nên đáp ứng với tất cả những yêu cầu tài liệu trên Những công cụ SQA giám sát quản lý cho bảo trì phần mềm Trong khi các công cụ SQA giám sát quản lý cụ thể được yêu cầu cho các hoạt động bảo trì sửa lỗi, thì sự giống nhau của các tiến trình phần mềm mô tả việc cải thiện chức năng và bảo trì thích ứng cũng như việc phát triển phần mềm cho phép những tiến trình này được sử dụng cùng một công cụ quản lý. Đặc biệt, các thành phần SQA quản lý có ý nghĩa giúp cải thiện việc điều khiển bảo trì bằng cách tạo ra những báo động sớm tín hiệu làm giảm chất lượng của các dịch vụ và tăng tỷ số thất bại dịch vụ. Phần còn lại của mục này sẽ đưa ra những vấn đề điều khiển quản lý chất lượng, những phần chính này đạt tới dịch vụ sửa lỗi phần mềm và hỗ trợ người dùng ở trên: $ Điều khiển hiệu năng cho các dịch vụ bảo trì sửa lỗi. 73

74 $ Đo chất lượng cho bảo trì sửa lỗi. $ Chi phí chất lượng bảo trì phần mềm. Điều khiển hiệu năng cho các dịch vụ bảo trì sửa lỗi Điều khiển hiệu năng quản lý cho các dịch vụ bảo trì sửa lỗi khác với khi áp dụng các dịch vụ sửa lỗi phần mềm và các dịch vụ hỗ trợ người dùng. Các công cụ điều khiển quản lý mang lại, bên cạnh thông tin hiệu năng theo chu kỳ, còn là những báo động sự chú ý quản lý, như sau: Sửa lỗi phần mềm " Tăng việc sử dụng tài nguyên " Giảm tỉ lệ sửa chữa lỗi từ xa so với sửa chữa on-site của khác hàng. " Tăng tỷ lệ sửa chữa on-site ở những vùng cục bộ ở xa so với các dịch vụ hải ngoại " Tăng phần trăm thất bại gặp phải khi sửa chữa yêu cầu lập lịch " Tăng tỉ lệ sửa lỗi, và liệt kê các trường hợp model cụ thể của các tình huống lỗi cực đoan. " Giảm bớt sự thỏa mãn khách hàng dựa trên các điều tra sự thỏa mãn của khách hàng. Hỗ trợ người sử dụng " Tăng tỉ lệ các yêu cầu dịch vụ cho các hệ thống phần mềm cụ thể, cho các kiểu dịch vụ, " Tăng tài nguyên được sử dụng cho các dịch vụ hỗ trợ người dùng " Tăng tỉ lệ thất bại của việc cung cấp các dịch vụ được yêu cầu " Tăng tỉ lệ lỗi, và trường hợp cụ thể của các thất bại đáng chú ý " Thông tin thỏa mãn khách hàng dựa trên các nghiên cứu sự thỏa mãn của khách hàng Những điều khiển sửa chữa lỗi quản lý này [những cái được mong đợi để đưa ra những cảnh bảo] được thực hiện qua báo cáo theo chu kỳ, qua buổi họp nhân viên đều đặn, qua việc xem xét các trung tâm hỗ trợ bảo trì cung cấp dịch vụ, qua phân tích báo cáo xử lý độ đo bảo trì phần mềm và giá thành chất lượng bảo trì. Thông tin được tích lũy hỗ trợ các quyết định quản lý quan tâm tới kế hoạch và việc thực hiện bảo trì sửa lỗi. Đo chất lượng bảo trì phần mềm Đo chất lượng bảo trì phần mềm được sử dụng chủ yếu để nhận biết khuynh hướng trong hiệu quả bảo trì, hiệu năng và sự thỏa mãn của khách hàng. Đơn vị đảm bảo chất lượng phần mềm thường thực hiện các tiến trình đo chất lượng. Thay đổi xu hướng tích cực hay tiêu cực, cung cấp cơ sở định lượng cho các quyết định quản lý, quan tâm tới: 74

75 " Ước lượng các yêu cầu tài nguyên khi lên kế hoạch bảo trì sửa chữa cho chu kỳ tiếp theo " So sánh các phương thức thực hiện " Khởi tạo các hoạt động ngăn ngừa và sửa lỗi " Ước lượng các yêu cầu tài nguyên như một cơ sở cho các đề xuất các dịch vụ bảo trì mới hoặc đã được điều chỉnh. Chi phí chất lượng phần mềm Như trong những phần trước, ở đây chúng ta chỉ quan tâm tới vấn đề bảo trì sửa lỗi. Giá thành chất lượng của bảo trì sửa lỗi được phân loại thành 6 lớp. Sau đây là định nghĩa cho mỗi lớp và ví dụ: Chi phí của việc ngăn ngừa: Chi phí ngăn ngừa lỗi, ví dụ như chi phí của việc xây dựng và đào tạo đội bảo trì, chi phí của các hoạt động ngăn ngừa và sửa lỗi. Chi phí của việc đánh giá chất lượng: chi phí của việc phát hiện lỗi, ví dụ như chi phí của việc xem xét lại các dịch vụ bảo trì được thực hiện bởi nhóm SQA, đội bên trong và các điều tra sự thỏa mãn của khách hàng. Chi phí của việc chuẩn bị và giám sát quản lý: Chi phí của các hoạt động quản lý được thực hiện để ngăn ngừa lỗi, ví dụ như chi phí của việc chuẩn bị kế hoạch bảo trì, việc tuyển đội bảo trì và bám sát hiệu năng bảo trì [follow-up of maintenance performance] Chi phí lỗi bên trong: Chi phí của lỗi phần mềm được đề xướng bởi đội bảo trì [ưu tiên cho các yêu sách nhận được từ phía khách hàng] Chi phí lỗi bên ngoài: Chi phí của các lỗi phần mềm được đề xướng bởi các yêu sách của khách hàng. Chi phí của lỗi quản lý: Chi phí lỗi phần mềm gây ra bởi các hoạt động quản lý hoặc tương tác, ví dụ như chi phí của các thiệt hại từ việc thiếu nhân viên bảo trì hoặc bảo trì không chính xác. Sau khi xem lại các lớp định giá thành chất lượng phần mềm, được định nghĩa theo các lớp cũng như mô hình mở rộng, sẽ được thảo luận kỹ hơn ở chương 22. Giá thành lỗi bên trong của các hoạt động bảo trì sửa lỗi phần mềm Để định nghĩa giá thành lỗi bên trong, có hai chu kỳ bảo trì phải được quan tâm riêng biệt. Đó là: [a] chu kỳ đảm bảo [warranty] [thường từ 3 đến 12 tháng sau khi cài đặt phần mềm] và [b] chu kỳ các dịch vụ bảo trì được ký hợp đồng, bắt đầu ở thời điểm kết thúc chu kỳ đảm bảo. Vấn đề ở đây yêu cầu một quyết định trong trường hợp nào nên quan tâm đến lỗi bên ngoài, chỉ sau khi đưa ra quyết định này thì việc định giá chất lượng mới 75

76 được xác định và ước lượng. Những định nghĩa được đề xuất về chi phí lỗi bên ngoài và các tham số của chúng cho các dịch vụ sửa lỗi phần mềm và hỗ trợ người dùng dưới đây: Cho sửa lỗi phần mềm: - Tất cả chi phí của sửa lỗi phần mềm được đưa ra bởi người sử dụng trong suốt chu kỳ đảm bảo là chi phí chất lượng bên ngoài bởi vì chúng đề cập tới kết quả trực tiếp từ lỗi phát triển phần mềm,hơn nữa người phát triển có trách nhiệm cho việc sửa lỗi của họ trong suốt chu kỳ này. - Sửa lỗi phần mềm được thực hiện trong suốt chu kỳ bảo trì được ký kết, nó được xem như là một phần chính của dịch vụ, khi trách nhiệm của người phát triển đối với việc sửa lỗi bị giới hạn ở chu kỳ đảm bảo. Chi phí của các dịch vụ này được xem là chi phí các dịch vụ chính thức chứ không phải là chi phí chất lượng.. - Trong suốt chu kỳ bảo trì kí kết, sau những nỗ lực của việc sửa lỗi ban đầu thì chỉ có chi phí cho việc sửa lỗi lại [re-correction] mới được xem là chi phí của lỗi bên ngoài. Cho các dịch vụ hỗ trợ người dùng: Trong suốt chu kỳ đảm bảo, các dịch vụ hỗ trợ người dùng được xem như là một phần của nỗ lực làm theo chỉ dẫn [instruction effort], và do vậy không nên quan tâm tới chi phí lỗi bên ngoài. Suốt chu kỳ bảo trì được kí kết, tất cả các kiểu dịch vụ hỗ trợ người dùng, dù là giải quyết một lỗi phần mềm được xác định hay bàn [consultation] về các tùy chọn ứng dụng, là tất cả các phần của dịch vụ chính thức, và chi phí của chúng không quan tâm tới chi phí lỗi bên ngoài. Trong cả hai chu kỳ bảo trì, một lỗi bên ngoài được định nghĩa như một trường hợp nơi sự bàn bạc thứ hai [second consultation] được yêu cầu sau khi sự bàn bạc ban đầu chứng minh là chính xác. Chi phí cung cấp cho sự bàn bạc thứ hai và kỹ hơn cho cùng một trường hợp được xem như là chi phí lỗi bên ngoài. Như trường hợp tổng quát, thông tin chi phí bảo trì chất lượng, cùng với thông tin giám sát quản lý khác được mong đợi nhằm giúp đỡ cho việc quản lý đưa ra quyết định, được quan tâm như sau: Chỉ dẫn cho việc đầu tư trong việc cải thiện các dịch vụ bảo trì bằng cách đưa ra điểm yếu của chi phí chất lượng cực cao và điểm mạnh của chi phí chất lượng cực thấp. Phát triển phiên bản được cải tiến của phần mềm [trong trường hợp phần mềm được làm cho khách hàng] hoặc việc thay thế gói phần mềm đã được mua. 76

77 3.4. Các CASE tool và ảnh hưởng của nó lên chất lượng phần mềm Khái niệm CASE tool Định nghĩa: Công cụ CASE là những công cụ máy tính để phát triển phần mềm mà chúng hỗ trợ người phát triển thực hiện một hoặc nhiều pha trong vòng đời của phần mềm và/hoặc hỗ trợ việc bảo trì phần mềm. Theo định nghĩa này thì những bộ biên dịch, hệ thống gỡ lỗi tương tác, hệ thống quản lý cấu hình và hệ thống kiểm thử tự động cũng được coi là công cụ CASE. Nói cách khác, những công cụ máy tính hỗ trợ việc phát triển phần mềm đã có từ lâu [ví dụ như những chương trình gỡ lỗi tương tác, bộ biên dịch hay hệ thống kiểm soát tiến trình dự án] có thể được xem là công cụ CASE cổ điển [classic CASE tool], trong khi đó những công cụ mới hỗ trợ người phát triển thực thi thành công các pha phát triển của dự án được xem là những công cụ CASE thực [real CASE tool]. Khi nhắc đến những công cụ CASE thực ta cần phải phân biệt giữa công cụ CASE bên trên [upper CASE tool] hỗ trợ pha phân tích và thiết kế với công cụ CASE bên dưới [lower CASE tool] hỗ trợ cho pha coding [trong đó bên trên và bên dưới liên quan đến vị trí các pha trong mô hình thác nước], và công cụ CASE tích hợp hỗ trợ pha phân tích, thiết kế và coding. Thành phần chính của công cụ CASE thực là một kho chứa [repository] chứa tất cả các thông tin liên quan đến dự án. Thông tin dự án được tích luỹ trong kho chứa và được cập nhật mỗi khi có sự thay đổi trong suốt quá trình phát triển phần mềm và trong cả giai đoạn bảo trì. Kho chứa của pha phát triển phía trước sẽ là cơ sở cho pha tiếp theo. Thông tin phát triển tích luỹ được chứa trong kho chứa cung cấp sự hỗ trợ cho giai đoạn bảo trì trong đó những công việc bảo trì sửa đổi, đáp ứng hay cải thiện chức năng được thực hiện. Hệ thống máy tính quản lý kho chứa đảm bảo thông tin dự án được duy trì và phù hợp với phương pháp luận phát triển mềm cũng như là đảm bảo các quy chuẩn dựa theo phong cách [style], các thủ tục xây dựng và chỉ dẫn công việc. Điều đó làm các công cụ CASE có khả năng đưa ra tài liệu dự án đầy đủ và cập nhật bất cứ lúc nào. Một vài công cụ CASE bên dưới và CASE tích hợp có thể tự động sinh ra mã chương trình dựa hoàn toàn trên thông tin thiết kế được lưu trong kho chứa. Những công cụ kỹ nghệ ngược [Reverse engineering tool] cũng được xem là các công cụ CASE thực. Dựa trên mã hệ thống, các công cụ này được áp dụng chính cho việc khôi phục và tái tạo tài liệu thiết kế cho hệ thống phần mềm đang được sử dụng [phần mềm kế thừa ]. Nói cách khác, những công cụ CASE kỹ nghệ ngược này hoạt động ngược với công cụ CASE thông thường: thay vì tạo ra mã hệ thống dựa trên thông tin thiết kế, chúng tạo ra kho chứa đầy đủ, cập nhật và tài liệu thiết kế dựa trên mã hệ thống. 77

78 Sự hỗ trợ của các công cụ CASE cho người phát triển hệ thống được thể hiện trong bảng sau: Kiểu công cụ CASE Sửa đổi và biểu đồ Truy vấn kho chứa Viết tài liệu tự động Hỗ trợ thiết kế Sửa đổi mã Sinh mã Quản lý cấu hình Kiểm thử phần mềm Kỹ nghệ ngược Quản lý dự án và chỉ số phần mềm Hỗ trợ Sửa đổi văn bản và biểu đồ, tạo biểu đồ thiết kế dựa trên các bản ghi trong kho chứa Hiển thị các phần của văn bản thiết kế, biểu đồ theo dõi yêu cầu Tự động sinh ra các tài liệu được yêu cầu theo các bản ghi cập nhật trong kho chứa Việc sửa đổi thiết kế được ghi lại bởi người phân tích hệ thống và quản lý từ điển dữ liệu Biên dịch, thông dịch và gỡ lỗi tương tác mã cho ngôn ngữ lập trình cụ thể hoặc công cụ phát triển Chuyển từ các bản ghi thiết kế sang mẫu hoặc ứng dụng phần mềm thích hợp với ngôn ngữ lập trình [hoặc công cụ phát triển] Quản lý phiên bản của tài liệu thiết kế và mã phần mềm, kiểm soát sự thay đổi trong thiết kế và mã phần mềm. Kiểm thử tự động, kiểm thử tải và quản lý kiểm thử và sửa bản ghi Xây dựng kho chứa phần mềm và tài liệu thiết kế, dựa trên mã của hệ thống phần mềm thừa kế. Khi kho chứa của phần mềm đã có, nó có thể được cập nhật và sử dụng để tự động tạo ra phiên bản mới của hệ thống Hỗ trợ việc quản lý dự án bằng cách theo dõi lịch và tính toán năng suất, chỉ số lỗi 78

79 Đóng góp của CASE tool cho chất lượng sản phẩm phần mềm Lợi ích của các công cụ CASE đối với chất lượng sản phẩm phần mềm đó là làm giảm một số lượng lớn các lỗi trong các pha phát triển phần mềm. Để đánh giá được lợi ích này, chúng ta cùng xem xét việc cải tiến chất lượng mà các công cụ CASE thực hiện được trong 9 nguyên nhân gây ra lỗi [được liệt kê trong phần 2.3]. Đánh giá của chúng ta sẽ bao gồm cả công cụ CASE cổ điển và thực. Bảng sau sẽ liệt kê những đóng góp của công cụ CASE tới việc cải thiện chất lượng phần mềm: Nguyên nhân gây ra lỗi Công cụ CASE cổ điển 1. Lỗi trong xác định yêu cầu 2. Việc thất bại trong giao tiếp giữa khách hàng và người phát triển 3. Sự chênh lệch có chủ ý trong yêu cầu phần mềm Công cụ CASE thực 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. Hầu như không đóng góp Trong hầu hết các trường hợp, việc xác định sự thất bại trong giao tiếp bằng máy tính là không thể. Những thất bại này chỉ có thể được xác định và ngăn chặn khi có thay đổi hoặc khi những thông tin khác được tìm thấy trở nên mâu thuẫn với những thông tin đã có. Đóng góp lớn Dựa trên những thông tin đã có, những chênh lệch từ yêu cầu được xác định như những mâu thuẩn và được liệt vào lỗi. Những chênh lệch này có thể được xác định bằng các công cụ theo dõi yêu cầu đã có và công cụ truy vấn [crossreferenced query tools]. 4. Những lỗi trong thiết Đóng góp lớn 79

80 kế theo logic Việc thiết kế lại [reengineering] 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. 5. Lỗi trong coding Đóng góp rất lớn Áp dụng những trình biên dịch [compiler, interpreters] và những trình gỡ lỗi tương tác [debugger] vào. 6. Không làm đúng với Đóng góp có giới hạn những chỉ dẫn về code Sử dụng những trình biên tập và viết tài liệu văn bản và kiểm định code để hỗ trợ chuẩn hóa cấu trúc, phong cách của văn bản, code và làm việc xác định những sai lệch không đúng dễ dàng hơn. 7. Những thiếu xót xảy Đóng góp lớn ra trong quá trình test Những công cụ kiểm tra tự Việc sử dụng nơi lưu trữ nhằm xác định những thiếu xót trong thiết kế, những thay đổi và những mâu thuẫn mới có với những bản ghi đã có [bản ghi đã được lưu trữ từ trước]. Đóng góp rất lớn Áp dụng các công cụ CASE bên dưới vào nhằm tạo ra một cách tự động những đoạn code tương thích hoàn toàn với thiết kế có sẵn. Thêm vào đó, vì code được tự động nên không có lỗi nào xảy ra. Đóng góp rất lớn Áp dụng những công cụ CASE bên dưới vào nhằm tạo ra những đoạn code đảm bảo làm đúng với những chỉ dẫn về code và viết tài liệu. Đóng góp lớn Áp dụng những công cụ 80

81 động 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 bằng máy tính làm giảm lỗi. 8. 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ý quản lý cấu hình. 9. Lỗi tài liệu Đóng góp có giới hạn Áp dụng duy nhất trình biên tập văn bản vào. CASE bên dưới, đặc biệt là những công cụ CASE được tích hợp vào để ngăn chặn lỗi trong coding và giảm lỗi thiết kế. Ứng dụng của những công cụ lưu trữ tới việc sửa lỗi và thay đổi trong suốt quá trình phát triển nhằm ngăn ngữa hầu hết các lỗi của phần mềm. Đóng góp có giới hạn Sử dụng những bản tài liệu đầy đủ và luôn cập nhật làm việc ngăn ngừa các lỗi bảo trì gây ra bởi những tài liệu không đầy đủ hoặc thiếu chính xác, đặc biệt nếu thiết kế đã được sửa lại nhiều lần. Đóng góp lớn Sử dụng nơi lưu trữ một cách tự động nhằm sinh ra những bản tài liệu đầy đủ và luôn cập nhật trước mỗi lần sửa lỗi và thay đổi Đó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 [đặt 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 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 cross-referenced 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 bằng các công cụ CASE tích hợp hay bên dưới hỗ trợ coding tự động mà sẽ không có lỗi [error] lập trình nào cũng như tài liệu tự động của việc sửa chữa. Bảo trì thích nghi [Adaptive maintenance]: 81

82 Tài liệu phần mềm đầy đủ và được cập nhật bởi các công cụ CASE cho phép xem xét kĩ lưỡng khả năng thích nghi của gói phần mềm đối với ứng dụng mới, người dùng mới. Bảo trì cải thiện chức năng [Functional improvement maintenance]: Việc sử dụng kho chưá cho phép những người thiết kế có thể đảm bảo tính nhất quán của các ứng dụng mới, các cải tiến mới với các hệ thống phần mềm vốn có. Các câu truy vấn kho chứa cross-referenced cho phép lên kế hoạch cho việc thay đổi, thêm chức năng một cách dễ dàng hơn Các thay đổi và việc thêm các chức năng thực hiện bằng các công cụ CASE tích hợp hay bên dưới cho phép coding tự động mà không có bất cứ lỗi [error] coding nào cũng như tài liệu tự động của các thay đổi và sửa chữa Đóng góp của CASE tool cho quản lý dự án [1] 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. [2] 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. Thông thường, việc áp dụng các công cụ CASE được mong đợi sẽ làm giảm giá thành và thời gian phát triển của dự án [ shorter time to market ]. Tuy nhiên, vai trò của các công cụ CASE đối với các khía cạnh chất lượng của quản lý dự án [gồm: điều khiển chi phí và thời gian] là trọng điểm sự quan tâm của chúng ta. Hiện nay, đã có trường hợp sử dụng công cụ CASE hiện đại làm giảm độ lệch giữa kinh phí thực thi và lịch biểu theo kế hoạch, đặc biệt bởi vì chúng ngăn ngừa lượng lỗi [error] và cho phép sửa lỗi nhanh, dễ dàng hơn khi có yêu cầu. Để việc quản lý dự án được cải thiện tốt hơn, công cụ điều khiển dự án [ở đây được xem là loại của các công cụ CASE cổ điển] và các phương pháp luận ước lượng thời gian, kinh phí được cải thiện phải được phát triể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 tham gia Những thành phần bên ngoài đóng góp vào dự án phần mềm Những người tham gia một dự án phát triển phần mềm tổ chức quan tâm đến hệ thống phần mềm[khách hàng] và tổ chức cam kết tiến hành phát triển [nhà thầu] ngày nay thường không chỉ là những người tham dự trong dự án. Những người tham gia bên ngoài có liên quan đến dự án phát triển phần mềm đóng góp cho dự án nhưng không phải là nhà thầu, mà cũng không phải là những thành viên của nhà thầu. Sự đóng góp của họ cho dự án được cấu trúc thông qua những thỏa thuận với nhà thầu [nhà thầu phụ hay những người cung cấp của COTS software] hoặc thông qua những điều khoản của hợp đồng dự án, các phần của dự án sẽ được thực thi bởi chính khách hàng của họ. Dự án lớn hơn và phức tạp hơn, có ý nghĩa hơn có thể đúng mà những người tham gia bên ngoài 82

83 được yêu cầu, phần lớn công việc được chuyển giao hoặc chia ra. Mục đích để chuyển hướng những người tham gia bên ngoài dựa vào một số nhân tố, xác định khoảng cách từ kinh tế đến kĩ thuật và đến những cá nhân liên quan [to personnel related interests], và mang lại một sự gia tăng mối quan tâm trong sự phân phối của công việc liên quan trong việc hoàn thành những 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: Subcontractors[ những nhà thầu phụ, hiện nay được gọi là những tổ chức outsourcing ] họ cam kết thực hiện các thành phần của 1 dự án, lớn hay nhỏ, tùy theo từng trường hợp. Những nhà thầu phụ thường đưa ra hợp đồng ở mức tối thiểu một trong những lợi ích: khả năng huy động nhân viên, ý kiến về mặt chuyên môn đặc biệt hoặc giá thấp. Những nhà cung cấp COTS software và những module phần mềm sử dụng lại. Lợi ích của sự tích hợp các thành phần đó là rất rõ ràng, sự xác định khoảnh cách từ kế hoạch làm việc và giảm bớt giá thành đến chất lượng. Một sự mong đợi mà sự tích hợp của những thành phần sẵn sàng để dùng sẽ được lưu trữ trong những mã nguồn phát triển, một 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 hơn thì được chờ đợi nhưng những thành phần đã được kiểm tra và được sửa chữa bởi những người phát triển, tốt như được sửa chữa theo những thiếu sót được xác định bởi khách hàng xem trước. Các tính chất của COTS software và các vấn đề chất lượng liên quan đến sử dụng chúng đã được nhận định bởi Basili và Boehm [2001]. Khách hàng, bản thân họ như là người tham gia thực hiện dự án. Điều này khá chung để mỗi khách hàng thực hiện các phần của dự án: để áp dụng những chuyên môn đặc biệt của những khách hàng, đáp ứng cho giao dịch hoặc những yêu cầu bảo mật khác, giữ lại những nhân viên phát triển nội bộ đang sử dụng, ngăn ngừa những vấn đề bảo mật trong tương lai.v.v. Trường hợp này có những hạn chế trong những điều khoản của quan hệ khách hàng-người cung cấp cần thiết để thực hiện thành công một dự án. Vì thế, chắc chắn trường hợp này đã trở thành 1 thành phần chuẩn của nhiều dự án phát triển phần mềm và những quan hệ bằng 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 hoàn thành của dự án. Trong đó trường hợp người tham gia ở bên ngoài cung cấp chậm những thành phần cho hệ thống phần mềm, dự án nói chung sẽ bị hoãn lại. Sự chậm trễ này chủ yếu là do nhà thầu phụ và khách hang gây ra chứ không phải do 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 kiểm soát sự phát triển phần mềm của nhà thầu phụ và khách hang không cao,do đó gây ra tình trạng chậm chạp,trì hoãn và không có thời 83

84 gian cho sự thay đổi cũng như thời gian cần thiết để tổ chức lại gây ảnh hưởng tiêu cực với 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 có thể phân loại như [a] sai sót: cao hơn so với số lượng sai sót mong đợi, thường cao hơn nhiều so với mong đợi [b] Coding và tài liệu không chuẩn : sự vi phạm của phong cách và cấu trúc trong việc xây dựng và các thủ tục[ theo giả thuyết như đã ấn định trong bât cứ hợp đồng nào]. Phần mềm chất lượng thấp và không chuẩn sẽ gây ra khó khăn trong giai đoạn kiểm thử và sau đó trong giai đoạn bảo trì. Việc yêu cầu thêm thời gian để kiểm tra và chỉnh sửa chất lượng phần mềm chất lượng thấp có thể gầy ra sự chậm trễ trong dự án đặc biệt trong trường hợp khi các thành viên bên ngoài hoàn thành nhiệm vụ của họ đúng thời hạn. - Khó khăn về bảo trì trong tương lai. Thực tế một số tổ chức tham gia việc phát triển nhưng chỉ một trong số họ, nhà thầu, là người trực tiếp gây nên 2 khó khăn trong việc bảo trì: a,nhà thầu có thể đối mặt với việc các coding và tài liệu không hoàn thành và/hoặc không đúng tiêu chuẩn từ các thành viên bên ngoài, gây ra sự kém chất lượng trong dịch vụ bảo trì của nhóm bảo trì và nhà thầu sẽ tốn chi phí cao hơn. b. Các dịch vụ bảo trì được cung cấp bởi nhiều hơn một tổ chức, có thể nhà thầu phụ, nhà cung cấp phần mềm có sẵn COTS và các bộ phận phát triển của khách hang.khi mổi phần này bị hạn chế khả năng đáp ứng, khách hàng buộc phải tìm kiếm người chịu trách nhiệm cho các lỗi cụ thể của phần mềm mỗi khi các lỗi này được phát hiện. - Mất sự kiểm soát các bộ phận của dự án Dù cố ý hay không cố ý,sự kiểm soát việc phát triển phần mềm của thành viên bên ngoài có thể tạo ra một bưc tranh lạc quan không thực tế về tình trạng của dự án. Sự trao đổi với nhóm các thành viên bên ngoài có thể làm gián đoạn tới một vài tuần,gây cản trở việc đánh giá tiến độ của dự án..kết quả là,cảnh báo về khó khăn trong phát triển, thiếu đội ngũ nhân viên và nhiều vấn đề khác đến muộn với các nhà thầu. Nhận thức được trước các khó khăn này, nhà thầu phải xem xét kết hợp lợi ích và rủi ro được đưa ra bởi các thành viên bên ngoài trong một dự án 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 Những mục tiêu nào thu được bằng việc áp dụng công cụ SQA được cung cấp bởi các thành viên bên ngoài? Những mục tiêu dưới đây có thể thu được trực tiếp từ việc liệt kê các rủi ro đã đề cập ở trên: Để 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 mưc độ chất lượng có thể chấp nhận được của bộ phận triễn khai và đón nhận cảnh báo sớm của phạm vi chất lượng yêu cầu. Để đảm bảo đủ tài liệu phục vụ cho nhóm bảo trì. 84

85 Để đả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 ta mong muốn các thành viên đóng góp bên ngoài thực hiện các các phương thức SQA của chính họ, bao gồm các công cụ cần thiết để các sản phẩm phần mềm và các dịch vụ của họ đạt được tới mức chất lượng có thể chấp nhận được. Các công cụ được đề cập tới ở đây là những thứ mà các nhà thầu có thể áp dụng cho các thành viên đóng góp bên ngoài. Trong mục đích này, vấn đề chất lượng và thời gian là quan trọng nhất được xác định. Các công cụ chính được áp dụng trước và trong suốt quá trình kết hợp các thành viên đóng góp bên ngoài trong một dự án phát triển phần mềm được liệt kê bên dưới. 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 85

86 Chương Một số khái niệm cơ bản Ví dụ về lỗi phần mềm a. Vụ thất bại tên lửa Patriot: Kiểm thử phần mềm xảy ra tại Dharan, Saudi Arabia, vào 25 tháng 2, 1991 làm 28 người chết nguyên nhân: vì lỗi rounding error [làm tròn] tên lửa Iraqi Hệ thống lá chắn của quân dự đoán 0.5km Doanh trại quân đội Mỹ [biểu diễn số 1/10 bằng số phẩy tĩnh cơ số 2] b. Vụ phát nổ Ariane 5: xảy ra tại tại Kourou, French Guiana, vào ngày 4 tháng sáu 1996 thiệt hại 500 triệu $ 86

87 nguyên nhân: vì lỗi tràn số [Overflow error] [vì biểu diễn số phẩy động [floating point] 64-bit bởi số phẩy tĩnh [fixed point] 16-bit] Phát nổ sau 40 giây rời khỏi mặt đất Đặc tả và lỗi phần mềm: a. Đặc tả if you can t say it, you can t do it a. Ta cần biết sản phẩm như thế nào trước khi ta có thể nói nó có lỗi. b. Đặc tả định nghĩa sản phẩm và: c. Yêu cầu chức năng mô tả các tính năng của sản phẩm. Ví dụ, calculator: d. Save, +, -, *, /, e. Yêu cầu phi chức năng là các ràng buộc về sản phẩm. Ví dụ, f. thân thiện với người dùng, hiệu năng, b. Lỗi phần mềm Phần mềm KHÔNG làm nhiệm vụ được đưa ra ở đặc tả [ví dụ, thiếu phép trừ] Phần mềm làm công việc mà đặc tả KHÔNG cho phép 87

88 Phần mềm làm công việc mà đặc tả không đề cập tới [ví dụ, tính căn bậc hai của số nguyên] Phần mềm không làm công việc mà đặc tả không đề cập tới nhưng nên làm [ví dụ, kiểm tra divided by 0] Phần mềm khó hiểu, khó dùng, chậm c. Chi phí sửa lỗi Chi phí sửa lỗi tăng theo cấp số nhân [10 x ] theo thời gian Ví dụ, một lỗi phát hiện trong pha đặc tả tốn $1 để sửa. nếu phát hiện trong pha thiết kế, tốn $10 nếu phát hiện trong pha cài đặt, tốn $100 nếu phát hiện sau khi phát hành, tốn $1000 d. Nguồn lỗi Đặc tả [Specification]: đặc tả lỗi, không đầy đủ, không nhất quán. Thiết kế [Design]: lỗi cơ bản trong thiết kế phần mềm. Cài đặt [Code]: lỗi lập trình, mã độc [malicious code]. Khác: Hệ thống hỗ trợ: Ngôn ngữ lập trình nghèo nàn, trình biên dịch có lỗi... Kiểm thử không đầy đủ: kiểm thử chưa xong, kiểm chứng nghèo nàn,... Cited from R. Patten s Software testing, SAMS publishing Kiểm thử và tiến trình kiểm thử a. Kiểm thử Kiểm thử phần mềm có nhiều định nghĩa khác nhau đề xuất bởi nhiều tổ chức hay cá nhân khác nhau. Một số định nghĩa nổi bật: 88

89 Kiểm thử phần mềm là quá trình khảo sát một hệ thống hay thành phần dưới những điều kiện xác định, quan sát và ghi lại các kết quả, và đánh giá một khía cạnh nào đó của hệ thống hay thành phần đó. [Theo Bảng chú giải thuật ngữ chuẩn IEEE của Thuật ngữ kỹ nghệ phần mềm- IEEE Standard Glossary of Software Engineering Terminology]. Kiểm thử phần mềm là quá trình thực thi một chương trình với mục đích tìm lỗi. [Theo The Art of Software Testing Nghệ thuật kiểm thử phần mềm]. Kiểm thử phần mềm là hoạt động khảo sát thực tiễn sản phẩm hay dịch vụ phần mềm trong đúng môi trường chúng dự định sẽ được triển khai nhằm cung cấp cho người có lợi ích liên quan những thông tin về chất lượng của sản phẩm hay dịch vụ phần mềm ấy. Mục đích của kiểm thử phần mềm là tìm ra các lỗi hay khiếm khuyết phần mềm nhằm đảm bảo hiệu quả hoạt động tối ưu của phần mềm trong nhiều ngành khác nhau. [Theo Bách khoa toàn thư mở Wikipedia]. Có thể định nghĩa một cách dễ hiểu như sau: Kiểm thử phần mềm là quá trình thực thi một hệ thống phần mềm để xác định xem phần mềm có đúng với đặc tả không và môi trường hoạt động có đúng yêu cầu không. Software testing objectives Các mục tiêu trực tiếp - Xác định và phát hiện nhiều lỗi nhất có thể trong phần mềm được kiểm thử - Sau khi sửa chữa các lỗi đã xác định và kiểm tra lại, làm cho phần mềm đã được kiểm thử đến một mức độ chấp nhận được về chất lượng. - Thực hiện các yêu cầu kiểm thử cần thiết một cách hiệu quả và có hiệu quả, trong phạm vi ngân sách và thời gian cho phép. Các mục tiêu gián tiếp Biên dịch một bản ghi về các lỗi phần mềm để sử dụng trong công tác phòng chống lỗi [bằng các hành động khắc phục và ngăn ngừa]. Cần lưu ý rằng thiếu sót của các mục tiêu thường xuyên để chứng minh gói phần mềm đã sẵn sàng không phải là ngẫu nhiên. Mục tiêu này vốn mâu thuẫn với mục tiêu đầu tiên đã được đề cập, và có thể ảnh hưởng hoặc chính xác hơn, xu hướng lựa chọn của test/ hoặc các trường hợp test. Myers[1979] đã đưa ra tóm tắt gọn gàng vấn đề : nếu mục tiêu của bạn là để hiển thị khi không có lỗi, bạn sẽ không phát hiện ra nhiều. Nếu mục tiêu của bạn là để cho thấy sự hiện diện của lỗi, bạn sẽ khám phá ra một tỷ lệ lớn lỗi. 89

90 Cách viết mục tiêu thứ 2 phản ánh một thực tế là việc không có lỗi phần mềm là một khát vọng không tưởng. Vì vậy chúng ta thích cụm từ mức độ chất lượng chấp nhận được, nghĩa là tỷ lệ các lỗi nhất định mà người dùng có thể chịu đựng được, sẽ vẫn chưa xác định khi cài đặt phần mềm. Tỷ lệ này thay đổi theo từng gói phần mềm và người sử dụng, nhưng phải thấp hơn cho những gói có nguy cơ thất bại cao Các mức kiểm thử Tuỳ thuộc vào mục tiêu của kiểm thử, ta chia ra thành các mức như sau: Mức 0: testing và debuging là giống nhau Mức 1: Mục tiêu của kiểm thử là để chỉ ra phần mềm hoạt động Mức 2: Mục tiêu của kiểm thử là để chỉ ra phần mềm không hoạt động Mức 3: Mục tiêu của kiểm thử là để giảm các rủi ro khi sử dụng phần mềm Mức 4: Nhằm trợ giúp các chuyên gia CNTT phát triển các phần mềm có chất lượng cao hơn. a. Mức 0 Testing và debuging là một Mức này thường được thực hiện bởi các sinh viên trong các môn học lập trình. Sinh viên viết chương trình, chạy với vài đầu vào, và debug lỗi nếu có. Mức này không phân biệt giữa hành vi không đúng và lỗi bên trong chương trình. Mức này chỉ giúp ích đôi chút trong việc phát triển phần mềm chính xác b. Mức 1 Nhằm để chứng minh tính đúng đắn. Một cách phát triển tự nhiên từ mức 0, tuy nhiên ta không thể chứng minh tính đúng đắn của phần mềm. Giả sử ta chạy một tập test và không phát hiện ra lỗi nào. Vậy, kết luận là gì? Liệu ta có thể giả thiết là phần mềm chạy tốt hay tập test kém? Vì không thể chứng minh tính đúng đắn, việc kiểm thử không có giới hạn dừng cố định, cũng như không có một kỹ thuật test hình thức [formal] nào. Nếu người quản lý hỏi: còn phải thực thi bao nhiêu test nữa? Ta không có cách nào trả lời chính xác câu hỏi này. c. Mức 2 Nhằm để chỉ ra lỗi. Tìm lỗi là một mục tiêu rõ ràng, nhưng mang tính tiêu cực. Tester có thể vui vẻ khi tìm ra lỗi, nhưng developers thì không muốn vậy - họ muốn phần mềm chạy [mức 1 là suy nghĩ tự nhiên của developers]. Do đó, mức 2 đặt tester và developers 90

91 vào quan hệ đối đầu. Điều này có thể ảnh hưởng xấu tới cả nhóm. Ngoài ra, câu hỏi đặt ra là nếu không tìm thấy lỗi nào thì sao? Ta có thể kết luận phần mềm chạy tốt? hoặc việc kiểm thử còn yếu? d. Mức 3 Kiểm thử có thể chỉ ra lỗi khi nó xuất hiện, nhưng không thể chứng tỏ phần mềm không có lỗi. Nghĩa là, ta phải chấp nhận mỗi khi sử dụng phần mềm, ta có nguy cơ gặp lỗi. Nguy cơ này có thể nhỏ, và không gây hậu quả gì, hoặc nguy cơ có thể lớn và gây ra thảm hoạ. Điều này chỉ ra rằng, toàn đội phát triển phần mềm có chung mục tiêu - giảm nguy cơ gặp lỗi khi sử dụng phần mềm. Ở mức 3, cả tester và developer làm việc cùng nhau để giảm nguy cơ gặp lỗi. e. Mức 4 Khi tester và developers có chung mục tiêu [mức 3], tổ chức có thể chuyển sang mức 4. Kiểm thử nhằm mục tiêu tăng chất lượng. Có nhiều cách để tăng chất lượng, trong đó tạo ra test có thể dẫn tới lỗi chỉ là một. Ở mức này, kỹ sư kiểm thử có thể trở thành trưởng nhóm kỹ thuật của dự án. Họ có nhiệm vụ đánh giá, cải thiện chất lượng phần mềm, và sự thẩm định của họ sẽ trợ giúp cho developers. Ví dụ như ta có 1 chương trình spell checker. Ta thường nghĩ nhiệm vụ chính của nó là để tìm những từ sai chính tả [đánh vần sai], nhưng thực tế, mục tiêu cao nhất của nó là để tăng khả năng viết chính tả của chúng ta. Mỗi khi spell checker tìm ra một từ sai chính tả, ta có cơ hội để học cách viết đúng. Do vậy, spell checker là chuyên gia về chất lượng viết chính tả. Một cách tương tự, mức 4 hướng tới mục tiêu kiểm thử để tăng khả năng của developers trong việc phát triển các phần mềm chất lượng cao. Testers có thể đào tạo developers Một số thuật ngữ Một số thuật ngữ liên quan tới kiểm thử lấy từ các tài liệu chuẩn [IEEE Standard Glossary of Software Engineering Terminology, DOD-STD-2167A and MIL-STD-498 from the US Department of Defense, and the British Computer Society s Standard for Software Component Testing] Validation [xác nhận]: Tiến trình đánh giá một phần mềm ở cuối quá trình phát triển phầm mềm để đảm bảo phù hợp với những dự định về sử dụng. Verification [xác minh, kiểm chứng]: tiến trình xác định xem liệu sản phẩm của một pha trong tiến trình phát triển phần mềm có đáp ứng đầy đủ yêu cầu được đưa ra trong pha trước đó. Xác minh thường là hoạt động có tính kỹ thuật cao hơn, sử dụng những tri thức về các 91

92 yêu cầu, đặc tả phần mềm. Xác nhận thường phụ thuộc vào tri thức về lĩnh vực tương ứng. Cụ thể là, tri thức về ứng dụng của phần mềm được viết. Ví dụ, xác nhận của phần mềm về máy bay yêu cầu tri thức từ kỹ sư hàng không và phi công. Cụm từ IV & V - independent verification and validation- nghĩa là xác nhận và xác minh độc lập. IV & V yêu cầu việc đánh giá phải được thực hiện bởi người không phải là lập trình viên. Một số trường hợp đội IV & V thuộc dự án, hoặc thuộc cùng công ty, cũng có thể thuộc một tổ chức độc lập. Vì sự độc lập của IV & V, tiến trình thường chưa bắt đầu cho tới khi dự án kết thúc và thường được thực hiện bởi chuyên gia trong lĩnh vực hơn là người phát triển phần mềm. Hai thuật ngữ hay dùng là fault và failure. Chúng liên quan tới suy nghĩ từ mức 0 sang mức 1. Sai sót [fault]: khuyết tật trong phần mềm Lỗi [error]: một trạng thái [bên trong] không chính xác là kết quả của fault Hỏng [failure]: hành vi không chính xác [bên ngoài] so với các yêu cầu hoặc mô tả về hành vi mong đợi. Ta hãy xem một ví dụ về bác sỹ chẩn đoán cho bệnh nhân. Bệnh nhân tới phòng khám với một danh sách failures [đó là các triệu chứng]. Bác sỹ phải phát hiện ra các fault, hoặc nguồn gốc của các triệu chứng. Để trợ giúp quá trình chẩn đoán, bác sỹ có thể phải yêu cầu thực hiện các kiểm tra về sự bất thường của các trạng thái bên trong, như cao huyết áp, nhịp tim bất thường, lượng đường trong máu cao, cholesterol cao. Với thuật ngữ của chúng ta, các bất thường này gọi là errors. Ta hãy xem xét một ví dụ về code Java sau: public static int numzero [int[] x] { // Effects: if x == null throw NullPointerException // else return the number of occurrences of 0 in x int count = 0; for [int i = 1; i < x.length; i++] { } if [x[i] == 0] { count++; } return count; 92

93 } fault ở đây là chương trình bắt đầu tìm kiếm các số bằng 0 từ chỉ số 1 thay vì chỉ số 0. Ví dụ numzero[[2,7,0]] được tính chính xác là 1, còn với numzero[[0,7,2]] sẽ được tính sai là 0. Trong cả 2 trường hợp, fault được thực thi. Mặc dù cả 2 trường hợp đều dẫn tới 1 lỗi, nhưng chỉ có trường hợp thứ 2 là gây ra failure. Để hiểu về trạng thái lỗi, ta cần định nghĩa trạng thái của chương trình. Trạng thái của numzero bao gồm giá trị của biến x, count, i và program counter [PC]. Với ví dụ đầu tiên, trạng thái ở câu lệnh if cho vòng lặp đầu tiên là [ x = [2, 7, 0], count = 0, i = 1, PC = if]. Lưu ý là trạng thái này là lỗi vì đáng ra i =0. Tuy nhiên, trạng thái lỗi này không được lan truyền tới output và do vậy phần mềm không fail. Nói cách khác, một trạng thái là nỗi nếu nó không phải là trạng thái như mong đợi dù cho tất cả các giá trị trong thạng thái là chấp nhận được. Tổng quát hơn, nếu chuỗi trạng thái mong đợi là s0,s1,s2... trong khi chuỗi trạng thái thực tế là s0,s2,s3... thì trạng thái s2 là lỗi. Với trường hợp thứ 2, trạng thái tương ứng là [x = [0, 7, 2], count = 0, i = 1, PC = if]. Trong trường hợp này, lỗi lan truyền tới kết quả trả về. Do vậy, ta thu được kết quả failure. Định nghĩa về fault và failure cho phép ta phân biệt giữa testing và debugging. 93

94 4.2. Các cấp độ kiểm thử Mối tương quan giữa phát triển và kiểm thử phần mềm Các cấp độ kiểm thử phần mềm 94

95 Kiểm thử đơn vị - Unit Testing Kiểm thử đơn vị là hoạt động kiểm thử nhỏ nhất Kiểm thử thực hiện trên các hàm hay thành phần riêng lẻ. Cần hiểu biết về thiết kế chương trình và code. Thực hiện bởi Lập trình viên [không phải kiểm thử viên] Đơn vị: Là thành phần nhỏ nhất của phần mềm có thể kiểm thử được. Ví dụ: Các hàm, lớp, thủ tục, phương thức. Đơn vị thường có kích thước nhỏ, chức năng hoạt động đơn giản, không gây nhiều khó khăn trong việc kiểm thử, ghi nhận và phân tích kết quả do đó nếu phát hiện lỗi việc tìm kiếm nguyên nhân và sửa lỗi cũng đơn giản và tốn ít chi phí hơn. Mục đích: Đảm bảo thông tin được xử lý đúng và có đầu ra chính xác trong mối tương quan giữa dữ liệu nhập và chức năng của đơn vị. Người thực hiện: Do việc kiểm thử đơn vị đòi hỏi phải kiểm tra từng nhánh lệnh, nên đòi hỏi người kiểm thử có kiến thức về lập trình cũng như về thiết kế của hệ thống nên người thực hiện thường là lập trình viên. Unit Test cũng đòi hỏi phải chuẩn bị trước các ca kiểm thử [Test case] hoặc kịch bản kiểm thử [Test script], trong đó chỉ định rõ dữ liệu đầu vào, các bước thực hiện và dữ liệu đầu ra mong muốn. Các Test case và Test script này nên được giữ lại để tái sử dụng Kiểm thử tích hợp - Integration Testing Kiểm thử tích hợp nhằm phát hiện lỗi giao tiếp xảy ra giữa các thành phần cũng như lỗi của bản thân từng thành phần [nếu có]. Thành phần có thể là các module các ứng dụng riêng lẻ các ứng dụng client/server trên một mạng Các loại kiểm thử tích hợp Big bang - Test toàn bộ phần mềm, một khi các gói đã hoàn thành có sẵn; có thể biết đến như là big bang testing. 95

96 Top-down kiểm thử từ gốc của hệ thống phân cấp thành phần. Các thành phần được thêm theo thứ tự giảm dần của hệ thống phân cấp. Bottom-up kiểm thử từ đáy của hệ thống phân cấp. Các thành phần được thêm theo thứ tự tăng dần của hệ thống phân cấp. Hình sau minh họa test top-down và test bottom-up của cùng một dự án phát triển phần mềm gồm 11 mô-đun. Hình [a], quá trình phát triển phần mềm và sự thử nghiệm tiếp thep được thực hiện theo bottom-up, trong 4 giai đoạn sau: - Giai đoạn 1: test các mô-đun từ 1 đến 7 - Giai đoạn 2: tích hợp test A của các mô-đun 1 và 2,đã phát triển và test ở giai đoạn 1, tích hợp với mô-đun 8, phát triển trong giai đoạn hiện thời. - Giai đoạn 3: hai sự kiểm tra tích hợp riêng biệt, B, trên các mô-đun 3,4,5 và 8, tích hợp với mô-đun 9, và C, mô đun 6 và 7 tích hợp với mô-đun 10 - Giai đoạn 4: test hệ thống được thực hiện sau khi B và C đã tích hợp với mô-đun 11, đã phát triển trong gia đoạn hiện thời. 1. Bottom-up testing 96

97 [b] Top-down testing Trong hình trên, phát triển phần mềm và kiểm thử được thực hiện từ trên xuống qua sáu giai đoạn : Giai đoạn 1: test mô-đun 11[unit test] Giai đoạn 2: tích hợp test A của mô-đun 11 tích hợp với mô-đun 9 và 10, phát triển trong giai đoạn hiện thời Giai đoạn 3: tích hợp test B của A tích hợp với mô-đun 8, phát triển trong giai đoạn hiện thời. Giai đoạn 4: tích hợp test C của B tích hợp với mô-đin 6 và 7, phát triển trong giai đoạn hiện thời Giai đoạn 5: tích hợp test D của C tích hợp với mô-đun 1 và 2, phát triển trong giai đoạn hiện thời Giai đoạn 6: test hệ thống của D tích hợp với mô-đun 3,4,5, phát triển trong giai đoạn hiện thời Việc gia tăng các đường trong hình trên chỉ có hai trong số nhiều các đường. Đường dẫn trong các ví dụ là trình tự theo chiều ngang [horizontally sequenced] 97

98 [ breadth first ], mặc dù ta có thể chọn một đường dẫn là trình tự theo chiều dọc[vertically sequenced] [ depth first ]. Nếu ta thay đổi đường ngang của top-down trong hình [b], với một dãy dọc, kiểm thử có thể được thực hiện như sau : - Giai đoạn 1: test đơn vị mô-đun 11 - Giai đoạn 2: tích hợp test A của tích hợp mô-đun 11 với mô-đun 9, phát triển trong giai đoạn hiện thời - Giai đoạn 3: tích hợp test B của A với mô-đun 8, phát triển trong giai đoạn hiện thời - Giai đoạn 4: tích hợp test C của B với các mô-đun 1 và 2, phát triển trong giai đoạn hiện thời - Giai đoạn 5: tích hợp test D của C với mô-đun 10, phát triển trong giai đoạn hiện thời - Giai đoạn 6: tích hợp test E của D với các mô-đun 6 và 7, phát triển trong giai đoạn hiện thời - Giai đoạn 7: test hệ thống được thực hiện sau khi sau khi E đã được tích hợp với các mô-đun 3,4 và 5, phát triển trong giai đoạn hiện thời. Các đường dẫn khác liên quan đến khả năng phân nhóm các mô-đun trong một giai đoạn kiểm thử. Ví dụ, đường dẫn trong top-down ở hình 9.1[b], một trong những nhóm mô-đun có thể là 8, 1 và 2 và/hoặc các mô-đun 10, 6 và 7. Stubs và drives để kiểm thử gia tăng Stubs và drives là phần mềm mô phỏng thay thế cho các mô-đun không có sẵn khi thực hiện một đơn vị hoặc kiểm thử tích hợp. Một stub [thường được cho là một mô-đun giả [ dummy module ] ] thay thế một mô-đun không có sẵn ở mức thấp hơn, mô-đun phụ để kiểm thử. Các Stub được yêu cầu cho kiểm thử top-down cho các hệ thống không đầy đủ. Trong trường hợp này, stub cung cấp kết quả tính toán của mô-đun phụ, chưa được phát triển [mã hóa], được thiết kế để thực hiện. Ví dụ, ở giai đoạn 3 của ví dụ top-down trong hình [b], mô-đun 9 phía trên kích hoạt mô-đun 8, có sẵn; nó đã được kiểm thử và đúng ở giai đoạn 2. Các stub được yêu cầu để thay thế cho các mô-đun phụ 1 và 2 là những mô-đun chưa được hoàn thành. Sự thiết lập kiểm thử này được trình bày trong hình dưới đây 98

99 Giống như một Stub, nhưng một driver là một mô-đun thay thế cho các mô-đun mức trên để kích hoạt kiểm thử các mô-đun. Driver là đi từ kiểm tra dữ liệu đến kiểm thử môđun và chấp nhận kết quả tính toán của nó. Driver được yêu cầu kiểm thử bottom-up cho tới khi các mô-đun ở mức cao được phát triển [mã hóa]. Ví dụ, ở giai đoạn kiểm thử 2 của ví dụ bottom-up trong hình [a], các mô-đun phụ 1 và 2 ở mức thấp hơn có sẵn; chúng đã được kiểm thử và đúng ở giai đoạn kiểm thử 1. Một driver được yêu cầu để thay thế cho mô-đun 9 chưa được hoàn thành. Sự thiết lập kiểm thử này được thể hiện trong hình [b]. Lưu ý Việc duy trì một thư viện các stub và driver để tái sử dụng trong tương lai có thể tiết kiệm đáng kể nguồn tài nguyên. - Các chiến lược Bottom-up so với Top-down Lợi thế chính của chiến lược Bottom-up là thực hiện tương đối dễ, trong khi bất lợi của nó chính là sự chậm trễ trong trường hợp toàn bộ chương trình được theo dõi [nghĩa là, ở giai đoạn kiểm thử mô-đun cuối cùng]. Lợi thế chính của chiến lược Topdown là khả năng nó cung cấp để chứng minh chức năng của toàn bộ chương trình một cách ngắn nhất ngay sau khi kích hoạt các mô-đun ở mức trên đã hoàn thành. Trong 99

100 nhiều trường hợp, các đặc trưng này cho phép xác định các lỗi liên quan đến thuật toán, các yêu cầu chức năng trong phân tích và thiết kế một cách sớm nhất. Bất lợi chính của chiến lược này là tương đối khó khăn trong việc chuẩn bị các stub được yêu cầu, thường yêu cầu lập trình phức tạp. Bất lợi khác là khó khăn trong việc phân tích kết quả kiểm thử. Các chuyên gia kiểm thử tiếp tục tranh luận xem chiến lược top-down hay bottom-up thích hợp hơn. Trong khi các quan điểm thay đổi, có vẻ như sự lựa chọn chiến lược thực sự được xác định trong hầu hết các trường hợp là sự lựa chọn phát triển không kiểm thử - chiến lược của các nhà phát triển, nghĩa là, bottom-up hoặc top-down. Rõ ràng, những người kiểm thử nên thực hiện theo phương pháp tiếp cận của nhà phát triển vì quan trọng là việc kiểm thử sẽ được thực hiện ngay khi một mô-đun đã được code. Thực hiện một chiến lược kiểm thử khác với chiến lược phát triển sẽ gây ra sự chậm trễ đáng kể của các cuộc kiểm thử. Big bang so với các chiến lược khác Trừ khi chương trình quá nhỏ và đơn giản, ứng dụng của chiến lược kiểm thử big bang chỉ ra những bất lợi nghiêm trọng. Xác định các lỗi trở nên khá rườm rà đối với số lượng lớn phần mềm. Mặc dù có nhiều nguồn lực đã đầu tư, hiệu quả của phương pháp này là tương đối khiêm tốn. Tỷ lệ nhận dạng lỗi tương đối thấp của big bang chứng minh cho kết luận này. Hơn nữa, khi đối đầu với toàn bộ gói phần mềm, việc sửa lỗi thường là nhiệm vụ nặng nề, cần phải xem xét những ảnh hưởng có thể của vài mô-đun tại cùng một thời điểm. Những ràng buộc hiển nhiên này tạo ra một nỗ lực khá mờ nhạt của việc ước lượng các nguồn lực kiểm thử cần thiết và tiến độ kiểm thử. Điều này cũng ám chỉ rằng triển vọng giữ đúng tiến độ và trong phạm vi ngân sách bị giảm đáng kể khi áp dụng chiến lược kiểm thử này Kiểm thử hệ thống - System Testing Kiểm thử hệ thống là một mức của tiến trình kiểm thử phần mềm khi các module và tích hợp các module đã được test. Mục tiêu của kiểm thử hệ thống là để đánh giá phần mềm có tuân thủ theo các yêu cầu đã đưa ra không. System Test lại gồm nhiều loại kiểm thử khác nhau, phổ biến nhất gồm: Kiểm thử chức năng [Functional Test]: Bảo đảm các hành vi của hệ thống thỏa mãn đúng yêu cầu thiết kế. Kiểm thử hiệu năng [Performance Test]: Bảo đảm tối ưu việc phân bổ tài 100

101 nguyên hệ thống [ví dụ bộ nhớ] nhằm đạt các chỉ tiêu như thời gian xử lý hay đáp ứng câu truy vấn... Kiểm thử mức độ đáp ứng [stress testing]: thực thi hệ thống với giả thiết là các tài nguyên hệ thống yêu cầu không đáp ứng được về chất lương, ổn định và số lượng. Kiểm thử cấu hình [Configuration Test]: phân tích hệ thống với các thiết lập cấu hình khác nhau. Kiểm thử độ ổn định [robustness testing]: kiểm thử dưới các điều kiện không mong đợi ví dụ như người dùng gõ lệnh sai, nguồn điện bị ngắt. Kiểm thử bảo mật [Security Test]: Bảo đảm tính toàn vẹn, bảo mật của dữ liệu và của hệ thống. Kiểm thử khả năng phục hồi [Recovery Test]: Bảo đảm hệ thống có khả năng khôi phục trạng thái ổn định trước đó trong tình huống mất tài nguyên hoặc dữ liệu; đặc biệt quan trọng đối với các hệ thống giao dịch như ngân hàng trực tuyến... Kiểm thử quá tải [overload testing]: đánh giá hệ thống khi nó vượt qua giới hạn cho phép. Kiểm nghiệm chất lượng [quality testing]: đánh giá sự tin tưởng, tính sẵn sàng của hệ thống. Bao gồm cả việc tính toán thừoi gian trung bình hệ thống sẽ bị hỏng và thời gian trung bình để khắc phục. Kiểm nghiệm cài đặt [Installation testing]: Người dùng sử dụng các chức năng của hệ thống và ghi lại các lỗi tại ví trị sử dụng thật sự. Lưu ý là không nhất thiết phải thực hiện tất cả các loại kiểm thử nêu trên. Tùy yêu cầu và đặc trưng của từng hệ thống, tuỳ khả năng và thời gian cho phép của dự án, khi lập kế hoạch, người Quản lý dự án sẽ quyết định áp dụng những loại kiểm thử nào Kiểm thử chấp nhận - Acceptance Testing Kiểm thử chấp nhận là một cấp độ trong tiến trình kiểm thử phần mềm nhằm kiểm thử hệ thống về khả năng chấp nhận được. Mục tiêu của kiểm thử này là để đánh giá sự tuân thủ của hệ thống với các yêu cầu nghiệp vụ và thẩm định xem đã có thể chấp nhận để bàn giao chưa. 101

102 Kiểm thử chấp nhận nhằm mục đích để chứng minh phần mềm thỏa mãn tất cả yêu cầu của khách hàng và khách hàng chấp nhận sản phẩm. Kiểm thử chấp nhận được khách hàng thực hiện [hoặc ủy quyền cho một nhóm thứ ba thực hiện]. Kiểm thử chấp nhận thông thường sẽ thông qua hai loại kiểm thử gọi là kiểm thử Alpha Alpha Test và kiểm thử Beta Beta Test. Với Alpha Test, người dùng kiểm thử phần mềm ngay tại nơi phát triển phần mềm, lập trình viên sẽ ghi nhận các lỗi hoặc phản hồi, và lên kế hoạch sửa chữa. Với Beta Test, phần mềm sẽ được gửi tới cho người dùng để kiểm thử ngay trong môi trường thực, lỗi hoặc phản hồi cũng sẽ gửi ngược lại cho lập trình viên để sửa chữa. Thực tế cho thấy, nếu khách hàng không quan tâm và không tham gia vào quá trình phát triển phần mềm thì kết quả Acceptance Test sẽ sai lệch rất lớn, mặc dù phần mềm đã trải qua tất cả các kiểm thử trước đó. Sự sai lệch này liên quan đến việc hiểu sai yêu cầu cũng như sự mong chờ của khách hàng Các kỹ thuật kiểm thử Kiểm thử hộp đen - Black-box Testing Black-box testing là phương pháp kiểm thử mà không cần biết cài đặt của chương trình. Cần có một bản chương trình chạy được và đặc tả Test cases được công thức hoá là một cặp ví dụ, [input, output mong muốn] Một số kỹ thuật thiết kế test: phân lớp tương đương, test biên, phân loại, kiểm thử theo cặp Quan trọng trong công nghiệp a. Phân lớp tương đương Equivalence Patitioning Phân lớp tương đương là một phương pháp kiểm thử hộp đen chia miền đầu vào của chương trình thành các lớp dữ liệu, từ đó suy dẫn ra các ca kiểm thử. Lớp tương đương biểu thị cho tập các trạng thái hợp lệ hay không hợp lệ đối với điều kiện vào. Thiết kế Test-case bằng phân lớp tương đương tiến hành theo 2 bước: 1. Xác định các lớp tương đương. 2. Xác định các ca kiểm thử. 102

103 Xác định các lớp tương đương Các lớp tương đương được xác định bằng cách lấy mỗi trạng thái đầu vào [thường là một câu hay một cụm từ trong đặc tả] và phân chia nó thành 2 hay nhiều nhóm. Ví dụ về các lớp tương đương: Từ các lớp tương đương trên ta có bảng liệt kê các lớp tương đương tương ứng: Điều kiện đầu vào x lớn hơn 0 và nhỏ hơn 100. Các lớp tương đương hợp lệ Các lớp tương đương không hợp lệ 25, 50, 75-50, -10, -1, 150, 200, 500 x lớn hơn 0. 10, 100, , -10, -1 Để xác định các lớp tương đương có thể áp dụng các nguyên tắc dưới đây: Một vùng giá trị Điều kiện đầu vào là một vùng giá trị. Ví dụ: Giá trị x chỉ có thể dao động từ 0 đến 100. Chúng ta sẽ xác định được 1 lớp tương đương hợp lệ là: 0