Tài liệu Đảm bảo chất lượng phần mềm

Nội dung text: Tài liệu Đảm bảo chất lượng phần mềm

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 PTIT Phan Thị Hoài Phương Hà Nội - 2010
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 nPTITộ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 9000-3, CMM và CMMI và các chuẩn tiến trình dự án như IEEE/EIA Std 12207, IEEE Std 1012, IEEE Std 1028. Chương 9. Tổ chức để đảm bảo chPTITấ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 8 1.1. Đặc điểm của phần mềm và môi trường phát triển phần mềm 8 1.2. Khái niệm phần mềm 11 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 12 1.3.1. Lỗi phần mềm 12 1.3.2. Nguyên nhân gây ra lỗi phần mềm 12 1.4. Định nghĩa chất lượng phần mềm và đảm bảo chất lượng phần mềm 15 1.5. Những mục tiêu đảm bảo chất lượng phần mềm 15 1.6. 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 16 Chương 2. Các thành phần chất lượng phần mềm tiền dự án 20 2.1. Rà soát hợp đồng 20 2.1.1. Tiến trình rà soát hợp đồng và các bước thực hiện 20 2.1.2. Các mục tiêu rà soát hợp đồng 21 2.1.3. Thực thi rà soát hợp đồng 24 2.1.4. Những khó khăn của thực hiện xem lại hợp đồng cho các đề xuất chính 25 2.1.5. Khuyến cáo cho việc thực hiện duyệt lại những hợp đồng chính 26 2.1.6. Các đối tượng rà soát hợp đồng 27 2.1.7. Rà soát hợp đồng cho các dự án nội bộ 27 2.2. Các kế hoạch phát triển và kế hoạch chất lượng 30 2.2.1. Những mục tiêu của kế hoạch phát triển và kế hoạch chất lượng 31 2.2.2. Các thành phần của kế hoạch phát triển 31 2.2.3. Các thành phần của kế hoạch chất lượng 35 2.2.4. 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ộ 38 Chương 3. Các thành phần SQA trong vòng đời dự án 41 3.1. Tích hợp các hoạt động chất lượng trong vòng đời dự án 41 3.1.1. Phương pháp phát triển phần mềm truyền thống và các phương pháp khác 41 3.1.2. Các yếu tố ảnh hưởngPTIT hoạt động đảm bảo chất lượng phần mềm 51 3.1.3. Xác minh, thẩm định và đánh giá chất lượng 52 3.2. Rà soát 53 3.2.1. Mục tiêu rà soát 53 3.2.2. Những rà soát thiết kế hình thức 54 3.2.3. Các rà soát ngang hàng (peer review) 56 3.2.4. Các ý kiến của chuyên gia 57 3.3. Đảm bảo chất lượng của các thành phần bảo trì phần mềm 59 3.3.1. Giới thiệu 59 3.3.2. Cơ sở cho chất lượng bảo trì cao 61 3.3.3. Các thành phần chất lượng phần mềm tiền bảo trì 64 3.3.4. Các công cụ đảm bảo chất lượng bảo trì phần mềm 68 3.4. Các CASE tool và ảnh hưởng của nó lên chất lượng phần mềm 77 3.4.1. Khái niệm CASE tool 77 3.4.2. Đóng góp của CASE tool cho chất lượng sản phẩm phần mềm 79 3.4.3. Đóng góp của CASE tool cho chất lượng bảo trì phần mềm 81 3.4.4. Đóng góp của CASE tool cho quản lý dự án 82 4
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 82 3.5.1. Những thành phần bên ngoài đóng góp vào dự án phần mềm 82 3.5.2. Rủi ro và lợi ích của giới thiệu người tham dự ngoài. 83 3.5.3. Những mục tiêu đảm bảo chất lượng về sự đóng góp người tham gia bên ngoài 84 3.5.4. Các công cụ đảm bảo chất lượng những đóng góp của các thành viên đóng góp bên ngoài. 85 Chương 4. Kiểm thử phần mềm 86 4.1. Một số khái niệm cơ bản 86 4.1.1. Ví dụ về lỗi phần mềm 86 4.1.2. Đặc tả và lỗi phần mềm: 87 4.1.3. Kiểm thử và tiến trình kiểm thử 88 4.1.4. Các mức kiểm thử 90 4.1.5. Một số thuật ngữ 91 4.2. Các cấp độ kiểm thử 94 4.2.1. Kiểm thử đơn vị - Unit Testing 95 4.2.2. Kiểm thử tích hợp - Integration Testing 95 4.2.3. Kiểm thử hệ thống - System Testing 100 4.2.4. Kiểm thử chấp nhận - Acceptance Testing 101 4.3. Các kỹ thuật kiểm thử 102 4.3.1. Kiểm thử hộp đen - Black-box Testing 102 4.3.2. Kiểm thử hộp trắng - White-box Testing (WBT) 108 4.3.3. Kiểm thử gia tăng - Incremental Testing 116 4.3.4. Thread Testing 116 4.3.5. Bảng tóm tắt Testing Levels/ Techniques 116 4.4. Quá trình kiểm thử 116 4.4.1. Xác định tiêu chuẩn chất lượng phần mềm phù hợp 116 4.4.2. Lập kế hoạch cho test 119 4.4.3. Thiết kế kiểm thử (test design) 121 4.4.4. Tiến trình test PTIT 124 4.4.5. Thiết kế trường hợp kiểm thử (Test Case Design) 125 Chương 5. Phân loại các phần mềm phục vụ kiểm thử 127 5.1. Phần mềm phục vụ kiểm thử 127 5.1.1. Phần mềm hỗ trợ viết tài liệu 127 5.1.2. Phần mềm quản lý lỗi 127 5.1.3. Công cụ kiểm thử tự động 129 5.2. Unit test và thư viện JUnit 133 5.2.1. Tổng quan về Unit Testing 133 5.2.2. Tổng quan thư viện Junit 135 Chương 6. Các thành phần cơ bản của chất lượng phần mềm 139 6.1. Thủ tục, chỉ dẫn và các thiết bị hỗ trợ chất lượng 139 6.1.1. Các thủ tục và chỉ dẫn 139 6.1.2. Chuẩn bị, thực thi và cập nhật các thủ tục và chỉ dẫn 142 6.1.3. Khuôn mẫu (templates) 143 6.1.4. Danh mục kiểm tra (Checklists) 146 6.2. Đào tạo đội ngũ và cấp chứng chỉ 148 5
6. 6.2.1. Mục tiêu của đào tạo và cấp chứng chỉ 149 6.2.2. Tiến trình đào tạo và cấp chứng chỉ 149 6.2.3. 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 150 6.2.4. Xác định những nhu cầu đào tạo và cập nhật (updating) 150 6.2.5. Lên kế hoạch đào tạo và chương trình cập nhật 151 6.2.6. Định nghĩa các vị trí yêu cầu cấp chứng chỉ 151 6.2.7. Lên kế hoạch các tiến trình cấp chứng chỉ 152 6.2.8. Phân phối các chương trình đào tạo và cấp chứng chỉ 153 6.2.9. Những công việc tiếp theo của việc đào tạo và cấp chứng chỉ 153 6.3. Các hành động sửa lỗi và phòng ngừa 154 6.3.1. Định nghĩa hoạt động sửa lỗi và phòng ngừa 154 6.3.2. Tiến trình hành động sửa lỗi và phòng ngừa 154 6.3.3. Thu thập, phân tích thông tin 155 6.3.4. Phát triển các giải pháp và thực thi 155 6.3.5. Tổ chức các hành động phòng ngừa và sửa lỗi 156 6.4. Quản lý cấu hình 157 6.4.1. Các thành phần cấu hình phần mềm 157 6.4.2. Quản lý cấu hình phần mềm 157 6.4.3. Kiểm soát sự thay đổi phần mềm 157 6.4.4. Kiểm soát quản lý cấu hình phần mềm 158 6.4.5. Các công cụ máy tính quản lý cấu hình phần mềm 159 6.5. Kiểm soát tài liệu 159 6.5.1. Các tài liệu kiểm soát và bản ghi chất lượng 159 6.5.2. Danh sách các tài liệu được kiểm soát 160 6.5.3. Chuẩn bị, phê chuẩn, lưu trữ và thu hồi tài liệu kiểm soát 160 Chương 7. Các thành phần quản lý chất lượng phần mềm 163 7.1. Điều khiển tiến độ dự án 163 7.1.1. Các thành phần điều khiển tiến độ dự án 163 7.1.2. Điều khiển tiến độ củPTITa các dự án nội bộ và các thành phần bên ngoài 163 7.1.3. Thực thi kiểm soát tiến độ dự án 163 7.1.4. Các công cụ kiểm soát tiến độ phần mềm 164 7.2. Độ đo chất lượng phần mềm 165 7.2.1. Các mục tiêu đo lường phần mềm và phân loại các độ đo 166 7.2.2. Các độ đo tiến trình 167 7.2.3. Các độ đo sản phẩm 170 7.2.4. Thực hiện đo chất lượng phần mềm 172 7.2.5. Những giới hạn của các độ đo phần mềm 173 7.3. Giá thành của chất lượng phần mềm 174 7.3.1. Các mục tiêu tính giá thành các độ đo chất lượng phần mềm 174 7.3.2. Mô hình truyền thống tính giá chất lượng phần mềm 174 7.3.3. Mô hình mở rộng tính giá chất lượng phần mềm 175 7.3.4. Các vấn đề trong áp dụng tính giá các độ đo chất lượng phần mềm 177 Chương 8. Các chuẩn, chứng chỉ và hoạt động đánh giá 178 8.1. Các chuẩn quản lý chất lượng 178 8.1.1. Phạm vi của các chuẩn quản lý chất lượng 178 6
7. 8.1.2. ISO 9001 và ISO 9000-3 178 8.1.3. Các mô hình tăng trưởng khả năng – phương pháp đánh giá CMM và CMMI 180 8.2. Các chuẩn tiến trình dự án SQA 181 8.2.1. IEEE/EIA Std 12207- các tiến trình vòng đời phần mềm 182 8.2.2. IEEE Std 1012 – xác minh và thẩm định 184 8.2.3. IEEE Std 1028 – rà soát 185 Chương 9. Tổ chức để đảm bảo chất lượng 187 9.1. Giới thiệu 187 9.1.1. Cơ cấu tổ chức phát triển phần mềm 187 9.1.2. Khung tổ chức phát triển phần mềm 187 9.2. Quản lý và vai trò của quản lý trong đảm bảo chất lượng phần mềm 188 9.2.1. Các hoạt động đảm bảo chất lượng của quản lý mức cao nhất 188 9.2.2. Những trách nhiệm quản lý phòng ban 190 9.2.3. Những trách nhiệm quản lý dự án 191 9.3. Đơn vị SQA và các tác nhân khác trong hệ thống SQA 192 9.3.1. Đơn vị SQA 192 9.3.2. Những ủy viên SQA và nhiệm vụ 193 9.3.3. Hội đồng SQA và nhiệm vụ 194 9.3.4. Nhiệm vụ và phương thức hoạt động của diễn đàn SQA 194 Tài liệu tham khảo 197 Phụ lục 198 PTIT 7
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 PTIT - 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 dPTITự á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ốngPTIT 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. 1.2. 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 PTITthiế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 1.3.1. 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 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. 1.3.2. 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 PTIT 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 cầ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ácPTIT 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átPTIT 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ọ. 1.4. Đị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 PTIThoặ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. 1.5. 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. 1.6. 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ếPTITu 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 hPTITệ 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ácPTIT 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 (man- day) 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 nhPTITữ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). 2.1.1. 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ênPTIT 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) 2.1.2. 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ọnPTIT 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áchPTIT 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àngPTIT 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 2.1.3. 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 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àPTIT 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 đồng 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ăPTITn cho một hoành thành mịn của nhiệm vụ. 2.1.4. 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. 2.1.5. 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ó PTITthể 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 để đưa ra quyết định để xem ở đâu để thực hiện xem lại. 2.1.6. Các đối tượng rà soát hợp đồng 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ể. 2.1.7. Rà soát hợp đồng cho các dự án nội bộ Một số lượng đáng kể, nếu khôngPTIT 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à "nhẹ" duyệt hợp , hoặc không ai cả. 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 Quản trị hoặc thao tác Hệ thống bán hàng và hàng mềm thao tác dùng trong tồn kho nội bộ Hệ thống quản lý tài chính Những gói phầm phầm Thị trường phần mềm Trò chơi máy tính được dự định để bán theo Phần mềm giáo dục kiểu “phần mềm đóng gói” Xử lý ngôn ngữ Những vi chương trình Bộ phận phát triển điện tử Công cụ điện tử và các phần được nhúng trong sản phẩm và cơ khí mềm điều khiển của công ty 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ươPTITng 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 đề Nhược điểm của khách hàng Nhược điểm của nhà phát nội bộ triển nội bộ Quá trình định nghĩa Cài đặt lệch hướng so với yêu Tốn nhân lực để đưa ra không tương xứng với cầu của chương trình những thay đổi có thể tránh yêu cầu dự án Hài lòng thấp Quá trình định nghĩa Mong đợi phi hiện thực một hệ Độ lệch lớn từ ngân sách không tương xứng với thống mềm dẻo phát triển yêu cầu dự án Xung đột được gây ra bởi các yêu cầu cho việc thêm PTITngân sách Thời khóa biểu / lập lịch Thiếu lịch trình ngày phân phối Hoạt động phát triển dưới trình nghèo nàn. sản phẩm mớ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 Chưa chuẩn bị cho những rủi ro Sự khởi đầu chậm chạm của nhận thức về những của dự án và những hậu quả nhân lực để khắc phục khó nguy cơ về rủi ro. của chúng. 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ànhPTIT 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 9000.3. Đâ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. 2.2.1. 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. 2.2.2. 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: PTIT 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. PTIT 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 vàng 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ếPTITt 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 roPTIT 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ể. 2.2.3. 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ượPTITng nhất định, như thể hiện trong bảng sau HDS qualitative Các mục tiêu định lượng chất lượng liên quan requirements (yêu cầu chất lượng ) HDS: thân thiện với Một thao tác mới trợ giúp công việc văn phòng có thể học người sử dụng 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: rất tin cậy 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 ) HDS: hoạt động liên tục 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 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 HDS: cung cấp dịch vụ Thời gian chờ đợi cho một thao tác phản hồi không vượt chất lượng cao cho quá 30 giây trong 99% lời yêu cầu.Những thành công của khách hàng 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ựPTITc 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ậnPTIT 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. 2.2.4. 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 PTITthiế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 240 000$, 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 trPTITể. 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á 385 000$ - 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 PTIT 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. 3.1.1. Phương pháp phát triển phần mềm truyền thống và các phương pháp khá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âyPTIT 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: PTIT 42
43. PTIT 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 phần phát triển. 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 suPTITố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 traPTIT 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. PTIT 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: • 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 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ọPTITa như hình dưới đây: 47
48. PTITMô 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. PTIT 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ênPTIT 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 3.1.2. Các yếu tố ảnh hưởngPTIT 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. 3.1.3. Xác minh, thẩm định và đánh giá chất lượng Ba khía cạnh đảm bảo chấPTITt 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. 3.2. Rà soát Định nghĩa của IEEE (1990), quá trình rà soát là: “Một quá trình hoặc 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 3.2.1. Mục tiêu rà soát Mục đích được chia làm 2 loại: mụPTITc đí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 lai. 53
54. 3.2.2. 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 PTIT - 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 : PTIT - 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 3.2.3. 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 độiPTIT (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áoPTIT 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 3.2.4. 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