Nội dung “Bài giảng Đảm bảo chất lượng ứng dụng – Phan Thị Hoài Phương” được xây dựng trong 9 chương. Chương 1 khái niệm về chất lượng ứng dụng và các yếu tố chất lượng ứng dụng. Chương 2 các thành phần chất lượng ứng dụng tiền dự án. Chương 3 các thành phần SQA trong vòng đời dự án. Chương 4 kiểm thử ứng dụng. Chương 5 phân loại các ứng dụng phục vụ kiểm…Mời các bạn cùng tham khảo.
Đang xem: đảm bảo chất lượng ứng dụng
<img class="aligncenter" decoding="async" src="https://thpttranhungdao.edu.vn/wp-content/uploads/23-0.jpg” alt=”*”>
ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀMBài giảng cho sinh viên ngành Công nghệ thông tin IT T P Phan Thị Hoài Phương Hà Nội – 2010 Giới thiệu Trước những thử thách trong quá trình tăng trưởng ứng dụng, việc đảm bảo chấtlượng ứng dụng (Software Quality Assurance-SQA) là hết sức quan trọng, yêu cầu phảinghiên cứu một cách nghiêm túc để thực thi hiệu quả. Tài liệu này phân phối những kiếnthức cơ bản về chất lượng ứng dụng, đảm bảo chất lượng trong một dự án phát triểnphần mềm. Qui trình xây dựng hệ thống đảm bảo chất lượng ứng dụng cũng được trìnhbày trong nội dung bài giảng. Qua đó, sinh viên hiểu được hình thức xây dựng một hệthống đảm bảo chất lượng ứng dụng 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ôngqua 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ầnmềm. Tài liệu được soạn phần lớn dựa trên cuốn sách Software Quality Assurance FromTheory to Implementation của Daniel Galin và một số tài liệu về kỹ nghệ ứng dụng,nhằm hỗ trợ cho sinh viên gặp vấn đề lúc đọ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: ITChương 1. Khái niệm về chất lượng ứng dụng và các yếu tố chất lượng ứng dụng Những khái niệm mở đầu của tài liệu được giới thiệu trong chương 1. Khởi đầu vớikhái niệm ứng dụng, chất lượng ứng dụng và đảm bảo chất lượng ứng dụng, phần tiếp Ttheo phân tích các yếu tố chất lượng ứng dụng.Chương 2. Các thành phần chất lượng ứng dụng tiền dự án P Chương này trình diễn những nội dung liên quan tới những thành phần đảm bảo chấtlượng ứng dụng tiền dự án bao gồm việc rà soát hợp đồng, kế hoạch tăng trưởng dự ánphần mềm và kế hoạch chất lượng ứng dụng.Chương 3. Các thành phần SQA trong vòng đời dự án Chương 3 nhắc đến tới các thành phần đảm bảo chất lượng ứng dụng trong vòng đờidự án ứng dụng. Những nội dung được trình diễn trong chương này bao gồm : phân tíchmột số mẫu hình tăng trưởng ứng dụng rộng rãi, các phương pháp rà soát, bảo trì phầnmềm và các dụng cụ CASE. Riêng kiểm thử ứng dụng là bước quan trọng sẽ được trìnhbày riêng ở chương 4.Chương 4. Kiểm thử ứng dụng Chương 4 nhắc đến tới kiểm thử ứng dụng. Những nội dung được trình diễn trongchươ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ử. 2Chương 5. Phân loại các ứng dụng phục vụ kiểm Chương 5 nhắc đến tới các loại thành phần được dùng trong kiểm thử ứng dụng.Những nội dung được trình diễn trong chương này bao gồm : các ứng dụng phục vụ kiểmthử và thư viện JUnit được sử dụng rộng rãi trong kiểm thử đơn vị cho tiếng nói lập trìnhJava.Chương 6. Các thành phần cơ bản của chất lượng ứng dụng Các thành phần cơ bản của chất lượng ứng dụng bao gồm các thủ tục (procedure), chỉdẫn (instruction), khuôn mẫu (templates), checklists (danh mục rà soát). Đó chính là nộidung được trình diễn trong phần đầu của chương 6. Phần tiếp theo sẽ trình diễn các hoạtđộng đảm bảo chất lượng ứng dụng khác như : tập huấn 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 ứng dụng Ngoài yếu tố kỹ thuật, trong các dự án tăng trưởng ứng dụng hiện đại, yếu tố quản lýđóng vai trò hết sức quan trọng. Chương 7 trình diễn các vấn đề liên quan tới quản lýchất lượng ứng dụng như : điều khiển tiến độ dự án, độ đo chất lượng ứng dụng, chi phíchất lượng ứng dụng. ITChương 8. Các chuẩn, chứng chỉ và hoạt động nhận định Chương này nhắc đến tới các chuẩn quản lý chất lượng như ISO 9001 và ISO 9000-3, TCMM và CMMI và các chuẩn tiến trình dự án như IEEE/EIA Std 12207, IEEE Std 1012,IEEE Std 1028. PChương 9. Tổ chức để đảm bảo chất lượng Trong những tổ chức lớn, quản lý nguồn nhân lực là một yếu tố quyết định sự thànhcông. Chương 9 nhắc đến tới các tác nhân tham gia vào hệ thống đảm bảo chất lượng phầnmề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ủachương.Phụ lụcTrình bày về các lỗi thường gặp lúc viết chương trình. 3MỤC LỤCGiới thiệu ……………………………………………………………………………………………………………. 2 Chương 1. Khái niệm về chất lượng ứng dụng và các yếu tố chất lượng ứng dụng …. 8 1.1. Đặc điểm của ứng dụng và môi trường tăng trưởng ứng dụng ……………………….. 8 1.2. Khái niệm ứng dụng ……………………………………………………………………………… 11 1.3. Lỗi ứng dụng và phân loại nguyên nhân gây ra lỗi ứng dụng ……………………. 12 1.3.1. Lỗi ứng dụng …………………………………………………………………………………. 12 1.3.2. Nguyên nhân gây ra lỗi ứng dụng …………………………………………………….. 12 1.4. Khái niệm chất lượng ứng dụng và đảm bảo chất lượng ứng dụng……………. 15 1.5. Những mục tiêu đảm bảo chất lượng ứng dụng ………………………………………… 15 1.6. Phân loại yêu cầu ứng dụng ứng với các yếu tố chất lượng ứng dụng ………… 16 Chương 2. Các thành phần chất lượng ứng dụng 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 trắc trở 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 nhân vật 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 IT 2.2. Các kế hoạch tăng trưởng và kế hoạch chất lượng…………………………………………. 30 2.2.1. Những mục tiêu của kế hoạch tăng trưởng và kế hoạch chất lượng …………… 31 2.2.2. Các thành phần của kế hoạch tăng trưởng………………………………………………. 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 tăng trưởng và kế hoạch chất lượng cho các dự án nhỏ và các dự T á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 P 3.1.1. Phương pháp tăng trưởng ứng dụng truyền thống và các phương pháp khác 41 3.1.2. Các yếu tố tác động hoạt động đảm bảo chất lượng ứng dụng …………… 51 3.1.3. Xác minh, thẩm định và nhận định 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ì ứng dụng …………………………. 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 ứng dụng tiền bảo trì ……………………………….. 64 3.3.4. Các dụng cụ đảm bảo chất lượng bảo trì ứng dụng ……………………………… 68 3.4. Các CASE tool và tác động của nó lên chất lượng ứng dụng …………………… 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 thành phầm ứng dụng ……………… 79 3.4.3. Đóng góp của CASE tool cho chất lượng bảo trì ứng dụng ………………….. 81 3.4.4. Đóng góp của CASE tool cho quản lý dự án ……………………………………….. 82 4 3.5. Đảm bảo chất lượng ứng dụng 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 ứng dụng ………………… 82 3.5.2. Rủi ro và lợi ích của giới thiệu người tham gia 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 dụ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ử ứng dụng…………………………………………………………………………. 86 4.1. Một số khái niệm cơ bản …………………………………………………………………………. 86 4.1.1. Ví dụ về lỗi ứng dụng ……………………………………………………………………… 86 4.1.2. Đặc tả và lỗi ứng dụng: …………………………………………………………………… 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 đơn vị quản lý độ 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 IT 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ử tăng thêm – Incremental Testing …………………………………………… 116 4.3.4. Thread Testing ………………………………………………………………………………. 116 4.3.5. Bảng tóm tắt Testing Levels/ Techniques …………………………………………. 116 T 4.4. Quá trình kiểm thử ……………………………………………………………………………….. 116 4.4.1. Xác định tiêu chuẩn chất lượng ứng dụng thích hợp …………………………… 116 4.4.2. Lập kế hoạch cho test ……………………………………………………………………… 119 P 4.4.3. Thiết kế kiểm thử (test design) ………………………………………………………… 121 4.4.4. Tiến trình test ………………………………………………………………………………… 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 ứng dụng phục vụ kiểm thử ……………………………………….. 127 5.1. Ứng dụng phục vụ kiểm thử …………………………………………………………………. 127 5.1.1. Ứng dụng hỗ trợ viết tài liệu …………………………………………………………… 127 5.1.2. Ứng dụng quản lý lỗi …………………………………………………………………….. 127 5.1.3. Dụ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 ứng dụng ………………………………. 139 6.1. Thủ tục, hướng dẫn và các thiết bị hỗ trợ chất lượng……………………………………… 139 6.1.1. Các thủ tục và hướng dẫn …………………………………………………………………….. 139 6.1.2. Sẵn sàng, thực thi và cập nhật các thủ tục và hướng dẫn ………………………….. 142 6.1.3. Khuôn mẫu (templates) …………………………………………………………………… 143 6.1.4. Danh mục rà soát (Checklists) ………………………………………………………. 146 6.2. Tập huấn hàng ngũ và cấp chứng chỉ …………………………………………………………… 148 5 6.2.1. Mục tiêu của tập huấn và cấp chứng chỉ ……………………………………………… 149 6.2.2. Tiến trình tập huấn và cấp chứng chỉ ………………………………………………….. 149 6.2.3. Xác định yêu cầu tri thức chuyên môn và sự cần thiết của tập huấn và cập nhật 150 6.2.4. Xác định những nhu cầu tập huấn và cập nhật (updating) ……………………… 150 6.2.5. Lên kế hoạch tập huấn và chương trình cập nhật …………………………………. 151 6.2.6. Khái niệm 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 tập huấn và cấp chứng chỉ …………………………. 153 6.2.9. Những công việc tiếp theo của việc tập huấn 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. Khái niệm 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. Tích lũy, phân tích thông tin …………………………………………………………… 155 6.3.4. Tăng trưởng 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 ứng dụng ………………………………………………….
Xem thêm: League Of Legends Maokai Mùa 11 : Bảng Ngọc Bổ Trợ Và Cách Lên Đồ Cho
Xem thêm: Download Wonder Zoo – Tải Xuống Wonder Zoo Mod Apk 2
157 6.4.2. Quản lý cấu hình ứng dụng ……………………………………………………………. 157 6.4.3. Kiểm soát sự thay đổi ứng dụng ……………………………………………………… 157 IT 6.4.4. Kiểm soát quản lý cấu hình ứng dụng ……………………………………………… 158 6.4.5. Các dụng cụ máy tính quản lý cấu hình ứng dụng …………………………….. 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 T 6.5.3. Sẵn sàng, phê duyệt, 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 ứng dụng …………………………………… 163 7.1. Điều khiển tiến độ dự án ……………………………………………………………………….. 163 P 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ủa 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 dụng cụ kiểm soát tiến độ ứng dụng………………………………………….. 164 7.2. Độ đo chất lượng ứng dụng ………………………………………………………………….. 165 7.2.1. Các mục tiêu đo lường ứng dụng 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 thành phầm ……………………………………………………………………….. 170 7.2.4. Thực hiện đo chất lượng ứng dụng …………………………………………………. 172 7.2.5. Những giới hạn của các độ đo ứng dụng ………………………………………….. 173 7.3. Giá thành của chất lượng ứng dụng ………………………………………………………. 174 7.3.1. Các mục tiêu tính giá thành các độ đo chất lượng ứng dụng ………………. 174 7.3.2. Mẫu hình truyền thống tính giá chất lượng ứng dụng………………………….. 174 7.3.3. Mẫu hình mở rộng tính giá chất lượng ứng dụng ……………………………….. 175 7.3.4. Các vấn đề trong vận dụng tính giá các độ đo chất lượng ứng dụng ……… 177 Chương 8. Các chuẩn, chứng chỉ và hoạt động nhận định ……………………………………… 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 8.1.2. ISO 9001 và ISO 9000-3…………………………………………………………………. 178 8.1.3. Các mẫu hình tăng trưởng khả năng – phương pháp nhận định 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 ứng dụng…………………….. 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 tăng trưởng ứng dụng ………………………………………………… 187 9.1.2. Khung tổ chức tăng trưởng ứng dụng …………………………………………………. 187 9.2. Quản lý và vai trò của quản lý trong đảm bảo chất lượng ứng dụng ………….. 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 ITTài liệu tham khảo ……………………………………………………………………………………………. 197 Phụ lục ……………………………………………………………………………………………………………. 198 T P 7Chương 1. Khái niệm về chất lượng ứng dụng và các yếu tố chất lượng ứng dụng 1.1. Đặc điểm của ứng dụng và môi trường tăng trưởng ứng dụng Có thể nói ứng dụng là một thành phầm đặc thù, nó ko giống như các sản phẩmcông nghiệp khác nên người ta thường gọi là tăng trưởng ứng dụng. Để phân biệt sự khácnhau giữa thành phầm ứng dụng với các thành phầm khác ta sẽ xem xét ba đặc điểm sau : (1) Độ phức tạp của thành phầm : Độ phức tạp của thành phầm có thể được đo bằng số lượng phương thức vận hành của thành phầm. Một thành phầm công nghiệp thậm chí là một máy tiên tiến cũng ko cho phép nhiều hơn vài trăm phương thức vận hành. Trong lúc đó, một gói ứng dụng 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à tăng trưởng đúng là một thử thách chính của công nghiệp ứng dụng. (2) Tính trực quan của sản phầm : Trong lúc các thành phầm công nghiệp có thể nhìn thấy được, thì các thành phầm ứng dụng đều vô hình. Hồ 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 IT 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 thành phầm công nghiệp ( ví dụ : một cái ôtô ko có cửa sổ ). Trái lại, các nhược điểm trong các thành phầm ứng dụng (được lưu trữ trong các đĩa mềm hay CD) đều ko nhìn thấy được, vì vậy, thực tiễn là các phẩn của một gói ứng dụng có T thể thiếu ngay từ đầu. (3) Tiến trình sản xuất và tăng trưởng ứng dụng : Các pha trong tiến trình sản xuất P một thành phầm – Tăng trưởng thành phầm : trong sản xuất công nghiệp, người thiết kế và các viên chức đảm bảo chất lượng rà soát nguyên mẫu để phát hiện các thiếu sót cuả chúng. Trong sản xuất ứng dụng, các chuyên gia đảm bảo chất lượng và đội tăng trưởng có xu thế tìm ra các lỗi thành 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ê duyệt, sẵn sàng để sản xuất. – Lập kế hoạch sản xuất thành 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 dụng cụ được thiết kế và sẵn sàng. Một số dòng thành phầm đặc thù cần phải được thiết kế và xây dựng. Do đó, pha này đã tạo thêm thời cơ xem xét thành phầm, và có thể phát xuất hiện các thiếu sót đã bị người rà soát và kiểm thử bỏ qua trong pha tăng trưởng. Trái lại, đây là pha ko yêu cầu trong tiến trình sản xuất ứng dụng, bởi việc sản xuất các bản copy ứng dụng và in các 8 sách hướng dẫn ứng dụng được thực hiện tự động. Điều này được vận dụng cho bất kỳ thành phầm ứng dụng 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 vận dụng để phát hiện lỗi sản xuất. Các thiếu sót trong thành phầm được phát xuất hiện ở thời kỳ trước 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ế thành phầm hoặc vật liệu, hay trong các dụng cụ sản xuất…Nhờ đó có thể tránh được các thiếu sót này trong các thành phầm được sản xuất trong tương lai. Trái lại, như đã nói ở phần trước, việc sản xuất ứng dụng đơn giản chỉ là sao chép các thành phầm và in các sách hướng dẫn, do đó việc phát hiện các thiếu sót của thành phầm rất khó khăn. Kỹ nghệ ứng dụng đã có những bước tăng trưởng đáng kể và vượt qua nhiều giai đoạnkhủng hoảng. Những kết quả nghiên cứu về kỹ nghệ ứng dụng đã giúp các tổ chức pháttriển ứng dụng một cách nhiều năm kinh nghiệm hơn. Môi trường tăng trưởng ứng dụng cũngmang 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ôitrường tăng trưởng cũng như môi trường bảo trì ứng dụng nhiều năm kinh nghiệm: IT (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à tăng trưởng ứng dụng và người dùng, các họat động bảo trì và phát triền ứng dụng cần đương đầu với các vấn đề : – Một danh sách các yêu cầu tính năng được xác định nhưng ứng dụng T được tăng trưởng và công việc bảo trì nó phải thực hiện. – Ngân sách dự án. P – Thời khắc biểu dự án.Nhà quản lý việc tăng trưởng ứng dụng và bảo trì dự án cần nỗ lực lớn trong việc giám sátcác hoạt động để đạt được các yêu cầu của hợp đồng. (2) Mối quan hệ người dùng – nhà phân phối : Trong suốt quá trình tăng trưởng và bảo trì ứng dụng, các hoạt động đều nằm dưới sự giám sát của người dùng. Đội dự án phải hợp tác liên tục với người dùng : để xem xét các yêu cầu thay đổi, để thảo luận những gì người dùng ko chấp thuận 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 tăng trưởng. (3) Yêu cầu làm việc theo nhóm : 3 yếu tố thường xúc tiến việc thành lập một đội dự án thay vì giao dự án cho một chuyên gia : 9 – Các yêu cầu về thời khắc 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 yêu cầu 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ông giống 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 ứng dụng khác : Để thực hiện được các dự án, đặc thù 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 rộng rãi trong công nghiệp ứng dụng. Trong các trường hợp như thế, có thể yêu cầu phải hợp tác với : – Các đội tăng trưởng ứng dụng khác trong cùng một tổ chức. – Các đội tăng trưởng phần cứng trong cùng một tổ chức. – Các đội tăng trưởng phần cứng và ứng dụng của các nhà phân phối khác. – Các đội tăng trưởng phần cứng và ứng dụng của người dùng – những IT người tham gia một phần vào sự tăng trưởng dự án.(5) Các giao diện với các hệ thống ứng dụng khác : Ngày nay, hồ hết hệ thống ứng dụng đều có các giao diện với các gói ứng dụng không giống nhau. Các giao diện này T 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 ứng dụng. Có thể khái niệm 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 ứng dụng khác truyền dữ P liệu tới hệ thống ứng dụng của bạn. – Các giao diện đầu ra – nơi hệ thống ứng dụng của bạn truyền dữ liệu đã được xử lý tới các hệ thống ứng dụng 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 kì tăng trưởng dự án là khá rộng rãi, 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ị thành khác…Người lãnh đạo đội phải thay thế các thành viên trong đội bởi các viên chức khác hoặc bởi một viên chức mới được tuyển dụng. Ko kể tới bao nhiêu nỗ lực cần đầu tư vào việc tập huấn một thành viên mới, việc thay đổi thành viên sẽ kéo theo thời kì thực hiện dự án sẽ thay đổi. 10 (7) Sự cần thiết phải tiếp tục thực hiện việc bảo trì ứng dụng trong một thời kì dài: Các người dùng sắm hoặc tăng trưởng một hệ thống ứng dụng mong đợi sẽ tiếp tục sử dụng nó trong một thời kì 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ồ hết trường hợp, dịch vụ bảo trì cần được phân phối trực tiếp bởi nhà tăng trưởng. Trong trường hợp các ứng dụng được tăng trưởng “trong nhà”, các người dùng “nội bộ” sẽ cùng san sẻ vấn đề bảo trì ứng dụng trong suốt thời kỳ dịch vụ của hệ thống ứng dụng. 1.2. Khái niệm ứng dụng Ứng dụng 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ốngMỗi thành phần ứng dụng đều có tính năng riêng và chất lượng của chúng đóng góp ITvào chất lượng chung của ứng dụng và bảo trì ứng dụng 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. T 2. Những thủ tục được yêu cầu để khái niệm theo một trật tự và lịch biểu của một chương trình lúc 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 ứng dụng P 3. Nhiều kiểu tài liệu là cần thiết cho người tăng trưởng, người sử dụng và người có nhiệm vụ duy trì. Tài liệu tăng trưởng (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à hiệp tác hiệu quả giữa các thành viên trong hàng ngũ tăng trưởng và hiệu quả trong việc xem lại và rà soát cá thành 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) phân phối một sự mô 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 tăng trưởng) phân phối 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 ứng dụng có sẵn. 4. Dữ liệu bao gồm các thông số đầu vào, mã nguồn và danh sách tên thích hợp với ứng dụng để đặ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 ko mong muốn trong mã nguồn hoặc dữ liệu ứng dụng đã từng xảy ra và những loại sự cố ứng dụng nào có thể được lường trước. 11 1.3. Lỗi ứng dụng và phân loại nguyên nhân gây ra lỗi ứng dụng 1.3.1. Lỗi ứng dụng Có nhiều nguyên nhân gây ra lỗi ứng dụng, biểu thị của các lỗi cũng không giống nhau ở mỗigiai đoạn tăng trưởng ứng dụng. Có ba loại lỗi ứng dụng chính :- Error: Là các phần của code nhưng ko đúng một phần hoặc toàn thể như là kết quả của lỗingữ 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ìnhviên hoặc các thành viên khác của đội tăng trưởng ứng dụng.- Fault: Là các errors nhưng nó gây ra hoạt động ko chuẩn xác của ứng dụng trong mộtứng dụng cụ thể.- Failures: Các faults trở thành failures chỉ lúc chúng được “activated” đó là lúc ngườidùng nỗ lực vận dụng các ứng dụng cụ thể đó bị faulty. Do đó, xuất xứ 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ềmIT Việc phát xuất hiện 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 ứng dụng thống kê sau đây đã được tổng kết sau nhiều năm nghiên cứu : 1. Khái niệm yêu cầu lỗi T 2. Lỗi giao tiếp giữa người dùng và người tăng trưởng 3. Sự thiếu rõ ràng của các yêu cầu ứng dụng P 4. Lỗi thiết kế logic 5. Lỗi coding 6.Ko thích 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: – Khái niệm 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 người dùng, là một trong những nguyên nhân chính của các lỗi ứng dụng. Các lỗi rộng rãi nhất loại này là: ■ Sơ sót trong khái niệm các yêu cầu. 12■ Ko có các yêu cầu quan trọng.■ Ko hoàn chỉnh khái niệm các yêu cầu.■ Bao gồm các yêu cầu ko cần thiết, các tính năng nhưng ko thực sự cần thiết trongtương lai gần.- Các lỗi trong giao tiếp giữa người dùng và nhà phát triểnHiểu lầm trong giao tiếp giữa người dùng và nhà tăng trưởng là nguyên nhân bổ sung chocác lỗi ưu tiên vận dụng trong thời kỳ đầu của quá trình tăng trưởng:■ Hiểu sai các hướng dẫn của người dù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 người dùng được trình diễn với nhà tăng trưởng bằngvăn bản trong thời kỳ tăng trưởng.■ Hiểu sai của các yêu cầu thay đổi của người dùng được trình diễn bằng lời nói với nhàphát triển trong thời kỳ tăng trưởng.■ Hiểu sai về phản ứng của người dùng đối với các vấn đề thiết kế trình diễn của nhà pháttriển. ITThiếu quan tâm tới các đề xuất của người dùng nhắc đến tới yêu cầu thay đổi và kháchhàng trả lời cho các câu hỏi nêu ra bởi nhà tăng trưởng trên một phần của nhà tăng trưởng.- Sai lệch có chủ ý từ các yêu cầu ứng dụng TTrong một số trường hợp, các nhà tăng trưởng có thể cố tình đi chệch khỏi các yêu cầutrong tài liệu, hành động thường gây ra lỗi ứng dụng. Các lỗi trong những trường hợp Pnày là thành phầm phụ của các thay đổi. Các tình huống thường gặp nhất là:■ Tăng trưởng các module ứng dụng Các thành phần sử dụng lại lấy từ một dự án trước đómà ko cần phân tích đầy đủ về những thay đổi và thích ứng cần thiết để thực hiệnmột cách chuẩn xác tất cả các yêu cầu mới.■ Do thời kì hay sức ép ngân sách, nhà tăng trưởng quyết định bỏ qua một phần của cácyêu cầu các tính năng trong một nỗ lực để ứng phó với những sức ép này.■ Nhà phát triển-khởi xướng, ko được chấp thuận các cải tiến cho ứng dụng,màkhông có sự chấp thuận của người dùng, thường xuyên bỏ qua các yêu cầu có vẻ nhỏ đốivới nhà tăng trưởng. Tương tự những thay đổi “nhỏ” có thể, cuối cùng, gây ra lỗi phầnmềm. 13- Các lỗi thiết kế logicLỗi ứng dụng có thể đi vào hệ thống lúc các chuyên gia thiết kế hệ thống-các kiến trúcsư hệ thống, kỹ sư ứng dụng, các nhà phân tích, vv – Xây dựng ứng dụng yêu cầu. Cáclỗi tiêu biểu bao gồm: + Khái niệm các yêu cầu ứng dụng bằng các thuật toán sai trái. + Thứ tự khái niệm có chứa trình tự lỗi. + Sơ sót trong các khái niệm biên + Thiếu sót trong các trạng thái hệ thống ứng dụng được yêu cầu +Thiếu sót trong khái niệm các hoạt động trái pháp luật trong hệ thống phầnmềm- Các lỗi codingMộ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àybao gồm sự hiểu lầm các tài liệu thiết kế, tiếng nói sơ sót trong tiếng nói lập trình, saisót trong việc vận dụng các CASE và các dụng cụ tăng trưởng khác, sơ sót trong lựa chọn ITdữ liệu…- Ko tuân thủ theo các tài liệu hướng dẫn và mã hóaHầu hết các đơn vị tăng trưởng có tài liệu hướng dẫn và tiêu chuẩn mã hóa riêng của mình Tđể 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ànhviên. Để hỗ trợ yêu cầu này, đơn vị tăng trưởng và công khai các mẫu và hướng dẫn mã Phóa. Các thành viên của nhóm tăng trưởng, đơn vị được yêu cầu phải thực hiện theo cácyêu cầu này.- Thiếu sót trong quá trình thử nghiệmThiếu sót trong quá trình thử nghiệm tác động tới tỉ lệ lỗi bằng cách để lại một số lỗilớn hơn ko bị phát hiện hoặc ko phát hiện đúng. Những kết quả yếu kém từ cácnguyên nhân sau đây:■ Kế hoạch thử nghiệm chưa hoàn chỉnh để lại phần ko được điều chỉnh của phầnmềm hoặc các tính năng ứng dụng và các trạng thái của hệ thống. Failures trong tài liệuvà báo cáo phát hiện sơ sót và lỗi lầm.■ Nếu ko kịp thời phát hiện và tu sửa lỗi ứng dụng theo như của hướng dẫn khôngphù hợp trong những lý do cho lỗi này.■ Ko hoàn thay đổi chữa các lỗi được phát hiện do sơ suất hay thời kì sức ép. 14- Các lỗi thủ tụcCá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ỗibước của quá trình. Chúng có tầm quan trọng đặc thù trong các hệ thống ứng dụng phứctạp, nơi các tiến trình được thực hiện một vài bước, mỗi bước trong số đó có thể có nhiềukiểu dữ liệu và cho phép rà soát các kết quả trung gian.- Các lỗi về tài liệuCác lỗi về tào liệu là vấn đề của các đội tăng trưởng và bảo trì đều có sơ sót trong tài liệuthiết kế và trong tài liệu hướng dẫn tích hợp trong thân của ứng dụng. Những lỗi này cóthể là nguyên nhân gây ra lỗi bổ sung trong thời kỳ tăng trưởng tiếp và trong thời gianbả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ủacác nhà phân tích hệ thống, lập trình, kiểm thử ứng dụng, các chuyên gia tài liệu, vàthậm chí cả các người dùng và đại diện của họ. 1.4. Khái niệm chất lượng ứng dụng và đảm bảo chất lượng ứng dụng IT Theo IEEE, chất lượng ứng dụng được khái niệm như sau :Chất lượng ứng dụng là: T! Mức độ nhưng 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 độ nhưng một hệ thống, thành phần hoặc một tiến trình đạt được những nhu cầu P hay mong đợi của người dùng hoặc người sử dụng. Lúc đầu đảm bảo chất lượng ứng dụng có mục tiêu đạt được các yêu cầu đề ra, tuynhiên thực tiễn tăng trưởng ứng dụng tồn tại rất nhiều ràng buộc yêu cầu người tăng trưởng cầntối ưu hóa công việc quản lý. Theo Daniel Galin, khái niệm đảm bảo chất lượng ứng dụng được xác định như sau : Đảm bảo chất lượng ứng dụng 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 để phân phối đầy đủ sự tin tưởng vào thứ tự tăng trưởng ứng dụng hayquy trình bảo trì ứng dụng của thành phầm hệ thống ứng dụng thích hợp với các yêu cầuchức năng kỹ thuật cũng như với các yêu cầu quản lý nhưng giữ cho lịch biểu và hoạt độngtrong phạm vi ngân sách. 1.5. Những mục tiêu đảm bảo chất lượng ứng dụng Tăng trưởng ứng dụng luôn đi đôi với bảo trì, vì vậy các hoạt động đảm bảo chấtlượng ứng dụng đều có mối liên quan chặt chẽ tới bảo trì. Những mục tiêu đảm bảo 15chất lượng ứng dụng tương ứng với thời kỳ tăng trưởng và bảo trì được xác định cụ thểnhư sau :- Tăng trưởng ứng dụng (hướng tiến trình)1. Đảm bảo một mức độ chấp thu được rằng ứng dụng sẽ thực hiện được các yêu cầuchức năng.2. Đảm bảo một mức đọ cấp thu được rằng ứng dụng sẽ giải quyết được các yêu cầu vềlịch biểu và ngân sách3. Thiết lập và quản lý các hoạt động để cải thiện và tăng lên hiệu quả của phát triểnphần mềm và các hoạt động SQA.- Bảo trì ứng dụng (hướng thành phầm)1. Đảm bảo một mức độ chấp thu được rằng các hoạt động bảo trì ứng dụng sẽ đáp ứngđược các yêu cầu tính năng.2. Đảm bảo một mức đọ cấp thu được rằng các hoạt động bảo trì ứng dụng sẽ đáp ứngđược các yêu cầu về lịch biểu và ngân sách IT3. Thiết lập và quản lý các hoạt động để cải thiện và tăng lên hiệu quả của bảo trì phầnmềm. 1.6. Phân loại yêu cầu ứng dụng ứng với các yếu tố chất lượng ứng dụng T Đã có nhiều tác giả nghiên cứu về các yếu tố chất lượng ứng dụng từ các yêu cầucả nó. Theo thời kì có thể quan niệm về việc đảm bảo chất lượng ứng dụng có phần Pthay đổi, tuy nhiên mẫu hình các yếu tố đảm bảo chất lượng ứng dụng của McCall ra đờivào những năm 70 của thế kỷ trước vẫn còn được nhiều người nhắc tới như là cơ sởtham chiếu các yêu cầu ứng dụng. Sau McCall cũng có một số mẫu hình được quan tâmnhư mẫu hình do Evans, Marciniak do hay mẫu hình của Deutsch và Willis, tuy nhiênnhững mẫu 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ácyếu tố chất lượng ứng dụng được chia làm ba loại :- Các yếu tố hoạt động của thành phầm bao gồm tính chuẩn xác, tin tưởng, hiệu quả, tính trọ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 IT Hình Cây mẫu hình yếu tố chất lượng ứng dụng theo McCallChi tiết các tính chất được phân tích như sau : (1) Các yếu tố vận hành thành phầm : Sự chuẩn xác, độ tin tưởng, tính hiệu quả, tính toàn T vẹn và khả năng sử dụng được : – Sự chuẩn xác : Các yêu cầu về độ chuẩn xác được xác định trong một danh sách P các đầu ra cần thiết của hệ thống ứng dụng, như màn hình hiển thị truy vấn số dư của người dùng trong một hệ thống thông tin kế toán bán hàng…Các đặc tả đầu ra thường là đa chiều, một số chiều thông dụng là : o Nhiệm vụ đầu ra (ví dụ : bản in hóa đơn bán hàng, hay đèn báo động đỏ lúc nhiệt độ tăng lên trên 250 độ F) o Độ chuẩn xác yêu cầu của các đầu ra này; chúng có thể bị tác động bất lợi bởi các tính toán ko chuẩn xác hay các dữ liệu ko chuẩn xác. o Tính đầy đủ của thông tin đầu ra; chúng có thể bị tác động bất lợi bởi dữ liệu ko đầy đủ. o Up-to-dateness của thông tin (xác định bằng thời kì giữa sự kiện và việc xem xét hệ thống ứng dụng. o Độ sẵn sàng của thông tin (thời kì phục vụ : được khái niệm là thời kì cần thiết để có được các thông tin yêu cầu) 17 o Các chuẩn cho việc code và viết tài liệu cho hệ thống ứng dụng.- Độ tin tưởng : Các yêu cầu về độ tin tưởng khắc phục các lỗi để phân phối dịch vụ. Chúng xác định tỉ lệ lỗi hệ thống ứng dụng tối đa cho phép, các lỗi này có thể là lỗi toàn thể hệ thống hoặc một hay nhiều tính năng riêng lẻ của nó.- Tính hiệu quả : Các yêu cầu về tính hiệu quả khắc phục 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 tính năng của hệ thống ứng dụng với sự thích 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 trị giá tối đa tài nguyên phần cứng được sử dụng trong hệ thống ứng dụng. Một yêu cầu khác về tính hiệu quả đó là thời kì 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 trọn vẹn khắc phục các vấn đề về bảo mật hệ thống ứng dụng, 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 IT lớn viên chức 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 T lực cần thiết để tập huấn một viên chức mới và để vận hành hệ thống ứng dụng.(2) Các yếu tố về rà soát thành phầm : bảo trì được, linh động và rà soát được : P- Khả năng bảo trì được : Các yêu cầu về khả năng bảo trì được sẽ xác định người dùng và viên chức 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 ứng dụng, để 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 ứng dụng, 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 ứng với một gói ứng dụng, với các người dùng trong cùng nghề, với các mức độ hoạt động không giống nhau, với các loại thành phầm không giống 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ở thành tuyệt vời, như thay đối và bổ sung vào ứng dụng để tăng dịch vụ của nó và để thích ứng với các thay đổi trong môi trường thương nghiệp và kỹ thuật của doanh nghiệp.- Khả năng test được : Các yêu cầu về khả năng rà soát được nói tới việc rà soát sự vận hành có tốt hay ko của các hệ thống thông tin. Các yêu cầu về khả 18 năng rà soát được liên quan tới các tính năng đặc thù 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 rà soát được liên quan tới vận hành ứng dụng bao gồm các chuẩn đoán tự động được thực hiện bởi hệ thống ứng dụng trước lúc khởi đầ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 ứng dụng đều làm việc tốt hay ko, 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 ứng dụng.(3) Các yếu tố về chuyển giao thành phầm : tính lưu động (khả năng thích ứng với môi trường), khả năng tái sử dụng và khả năng hiệp 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 ứng của hệ thống ứng dụng với các môi trường khác, bao gồm phần cứng khác, các hệ quản lý khác…Các yêu cầu này yêu cầu các ứng dụng 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 nhiều chủng loại.- 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 IT các modul ứng dụng trong một dự án mới đang được tăng trưởng nhưng các modul này thuở đầ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 tăng trưởng. Tái sử dụng ứng dụng sẽ tiết kiệm tài nguyên phát T triển, rút ngắn thời kì tăng trưởng 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ả thiết rằng hồ hết các lỗi ứng dụng đều P được phát hiện bởi các hoạt động đảm bảo chất lượng ứng dụng thực hiện trên ứng dụng thuở đầu, bởi những người sử dụng ứng dụng thuở đầ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 ứng dụng đã trở thành một phần trong chuẩn công nghiệp ứng dụng (IEEE,1999).- Khả năng hiệp tác : Các yêu cầu về khả năng hiệp tác tập trung vào việc tạo ra các giao diện với các hệ thống ứng dụng khác. Các yêu cầu về khả năng hiệp tác có thể xác định tên của ứng dụng với giao diện buộc phải. 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. 19Chương 2. Các thành phần chất lượng ứng dụng tiền dự án 2.1. Rà soát hợp đồng Một hợp đồng tồi cứng cáp là khó có thể chấp thu được. Từ ý kiến của SQA,một hợp đồng tồi – thường mô tả các yêu cầu ko chặt chẽ và đưa ra kế hoạch cũngnhư ngân sách phi thực tiễn – thì sẽ dẫn tới một ứng dụng có chất lượng tồi. Vì thế, mộtchương trình SQA cần được thực hiện để đảm bảo chất lượng ứng dụng bằng cách ràsoát lại những đề xuất thuở đầ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 tiêu cảithiện ngân sách và thời khắc biểu, là những cơ sở cho những đề xuất và hợp đồng saunà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 thuở đầ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ệnCó khá nhiều tình huống có thể giúp một doanh nghiệp ứng dụng (“nhà phân phối”) ký hợp ITđồng với một người dùng. Phổ thông 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) T của người dùng • Nhận một đặt hàng từ một người dùng của doanh nghiệp P • Nhận một yêu cầu từ bên trong hoặc từ phòng ban khác trong một tổ chứcRà 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ạinhữ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 phân phối sự giám sát những hợp đồng được thực hiện với những đối tác dự ántiềm năng và các nhà thầu phụ. Tiến trình ra soát có thể được phân thành hai thời kỳ: • Thời đoạn 1: rà soát lại bản dự thảo đề xuất trước lúc ủy quyền người dùng tiềm năng (“rà soát bản dự thảo đề xuất”). Thời đ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 người dùng, cụ thể yêu cầu thêm của người dùng và dự diễn giải các yêu cầu, các ước tính chi phí và tài nguyên, những hợp đồng ngày nay hoặc là những bản dự thảo hợp đồng của nhà phân phối với các đối tác và nhà thầu phụ. • Thời đoạn 2: rà soát lại bản dự thảo hợp đồng trước lúc kí (“rà soát bản dự thảo hợp đồng”). Thời đoạn này rà soát lại bản dự thảo hợp đồng dựa trên đề 20
Bạn thấy bài viết Hướng dẫn Sqa Là Gì? Đảm Bảo Chất Lượng Phần Mềm (Quality Assurance) Có Giống có khắc phục đươc vấn đề bạn tìm hiểu ko?, nếu ko hãy comment góp ý thêm về Hướng dẫn Sqa Là Gì? Đảm Bảo Chất Lượng Phần Mềm (Quality Assurance) Có Giống bên dưới để thpttranhungdao.edu.vn có thể thay đổi & cải thiện nội dung tốt hơn cho độc giả nhé! Cám ơn bạn đã ghé thăm Website Trường THPT Trần Hưng Đạo
Phân mục: Hỏi đáp
Nguồn: thpttranhungdao.edu.vn
Trả lời