Đảm bảo chất lượng phần mềm

ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM PT IT Bài giảng cho sinh viên ngành Công nghệ thông tin Phan Thị Hồi Phương Đỗ Thị Bích Ngọc Hà Nội - 2016 Giới thiệu Trước thách thức 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) quan trọng, đòi hỏi phải nghiên cứu cách nghiêm túc để thực thi hiệu Tài liệu cung cấp kiến thức chất lượng phần mềm, đảm bảo chất lượng 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 trình bày nội dung giảng Qua đó, sinh viên hiểu cách thức xây dựng hệ thống đảm bảo chất lượng phần mềm vai trò thành viên hệ thống Một số chuẩn đảm bảo chất lượng giới thiệu chương cuối Thông qua nội dung giảng sinh viên nắm kỹ rà soát kiểm thử phần mềm Tài liệu soạn phần đầu dựa sách Software Quality Assurance From Theory to Implementation Daniel Galin số tài liệu chuyên ngành khác Nội dung giảng xây dựng bảy chương: IT Chương Khái niệm chất lượng phần mềm yếu tố chất lượng phần mềm PT Những khái niệm mở đầu tài liệu giới thiệu chương Bắt đầu với khái niệm phần mềm, chất lượng phần mềm đảm bảo chất lượng phần mềm, phần phân tích yếu tố chất lượng phần mềm Chương Các thành phần chất lượng phần mềm tiền dự án Chương trình bày nội dung liên quan đến 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 kế hoạch chất lượng phần mềm Chương Các thành phần SQA vòng đời dự án Chương đề cập đến thành phần đảm bảo chất lượng phần mềm vòng đời dự án phần mềm Những nội dung trình bày chương bao gồm : phân tích số mơ hình phát triển phần mềm phổ biến, phương pháp rà sốt, bảo trì phần mềm Riêng kiểm thử phần mềm bước quan trọng trình bày riêng chương Chương Kiểm thử phần mềm Chương đề cập đến kiểm thử phần mềm Những nội dung trình bày chương bao gồm : khái niệm bản, mức kiểm thử, kỹ thuật kiểm thử, trình kiểm thử Chương Phân loại phần mềm phục vụ kiểm Chương đề cập đến loại thành phần dùng kiểm thử phần mềm Những nội dung trình bày chương bao gồm : phần mềm phục vụ kiểm thử công cụ hỗ trợ kiểm thử tự động, gồm thư viện JUnit sử dụng rộng rãi kiểm thử đơn vị cho ngôn ngữ lập trình Java, cơng cụ Selenium dùng rộng rãi kiểm thử ứng dụng Web Chương Các chuẩn, chứng hoạt động đánh giá Chương đề cập tới chuẩn quản lý chất lượng ISO, CMM/CMMI, sâu vào CMM/CMMI Phụ lục PT IT Trình bày lỗi thường gặp viết chương trình PT IT MỤC LỤC Giới thiệu Chương 1.Khái niệm chất lượng phần mềm yếu tố chất lượng phần mềm 1.1 Đặc điểm phần mềm môi trường phát triển phần mềm 1.2 Khái niệm phần mềm 10 1.3 Lỗi phần mềm phân loại nguyên nhân gây lỗi phần mềm 11 1.3.1 Lỗi phần mềm 11 1.3.2 Nguyên nhân gây lỗi phần mềm 11 1.4 Định nghĩa chất lượng phần mềm đảm bảo chất lượng phần mềm 14 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 yếu tố chất lượng phần mềm 15 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à sốt hợp đồng bước thực 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 thực xem lại hợp đồng cho đề xuất 25 2.1.5 Khuyến cáo cho việc thực duyệt lại hợp đồng 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 dự án nội 27 2.2 Các kế hoạch phát triển kế hoạch chất lượng 29 2.2.1 Những mục tiêu kế hoạch phát triển kế hoạch chất lượng 30 2.2.2 Các thành phần kế hoạch phát triển 31 2.2.3 Các thành phần kế hoạch chất lượng 34 2.2.4 Các kế hoạch phát triển kế hoạch chất lượng cho dự án nhỏ dự án nội 37 Chương 3.Các thành phần SQA vòng đời dự án 41 3.1 Tích hợp hoạt động chất lượng 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 phương pháp khác 41 3.1.2 Các yếu tố ảnh hưởng hoạt động đảm bảo chất lượng phần mềm 45 3.1.3 Xác minh, thẩm định đánh giá chất lượng 46 3.2 Rà soát 47 3.2.1 Mục tiêu rà soát 47 3.2.2 Những rà sốt thiết kế hình thức 47 3.2.3 Các rà soát ngang hàng (peer review) 50 3.2.4 Các ý kiến chuyên gia 52 3.2.5 Một số biểu mẫu rà sốt 54 3.3 Đảm bảo chất lượng thành phần bảo trì phần mềm 63 3.3.1 Giới thiệu 63 3.3.2 Cơ sở cho chất lượng bảo trì cao 65 3.3.3 Các thành phần chất lượng phần mềm tiền bảo trì 67 3.3.4 Các cơng cụ đảm bảo chất lượng bảo trì phần mềm 71 3.4 Đảm bảo chất lượng phần mềm yếu tố bên tham gia 81 3.4.1 Những thành phần bên ngồi đóng góp vào dự án phần mềm 81 3.4.2 Rủi ro lợi ích giới thiệu người tham dự 82 PT IT 3.4.3 Những mục tiêu đảm bảo chất lượng đóng góp người tham gia bên ngồi 83 3.4.4 Các cơng cụ đảm bảo chất lượng đóng góp thành viên đóng góp bên 84 Chương 4.Kiểm thử phần mềm 85 4.1 Một số khái niệm 85 4.1.1 Ví dụ lỗi phần mềm 85 4.1.2 Đặc tả lỗi phần mềm: 86 4.1.3 Kiểm thử tiến trình kiểm thử 87 4.1.4 Các mức kiểm thử 89 4.1.5 Một số thuật ngữ 90 4.2 Các cấp độ kiểm thử 93 4.2.1 Kiểm thử đơn vị - Unit Testing 94 4.2.2 Kiểm thử tích hợp - Integration Testing 94 4.2.3 Kiểm thử hệ thống - System Testing 99 4.2.4 Kiểm thử chấp nhận - Acceptance Testing 100 4.3 Các kỹ thuật kiểm thử 101 4.3.1 Kiểm thử hộp đen - Black-box Testing 101 4.3.2 Kiểm thử hộp trắng - White-box Testing (WBT) 107 4.3.3 Kiểm thử gia tăng - Incremental Testing 114 4.3.4 Thread Testing 114 4.3.5 Bảng tóm tắt Testing Levels/ Techniques 114 4.4 Quá trình kiểm thử 114 4.4.1 Xác định tiêu chuẩn chất lượng phần mềm phù hợp 114 4.4.2 Lập kế hoạch cho test 117 4.4.3 Thiết kế kiểm thử (test design) 119 4.4.4 Tiến trình test 122 4.4.5 Thiết kế trường hợp kiểm thử (Test Case Design) 124 Chương 5.Các phần mềm dùng kiểm thử 125 5.1 Phần mềm phục vụ kiểm thử 125 5.1.1 Phần mềm hỗ trợ viết tài liệu 125 5.1.2 Phần mềm quản lý lỗi 125 5.1.3 Công cụ kiểm thử tự động 127 5.2 Unit test thư viện JUnit 131 5.2.1 Tổng quan Unit Testing 131 5.2.2 Tổng quan thư viện Junit 133 5.3 Kiểm thử ứng dụng web với Selenium 137 5.3.1 Khái quát Selenium 137 5.3.2 Selenium WebDriver 139 5.3.3 Các câu lệnh sử dụng Selenium WebDriver 140 Chương 6.Các chuẩn, chứng hoạt động đánh giá 144 6.1 Các chuẩn quản lý chất lượng 144 6.1.1 Giới thiệu CMM/CMMI 144 6.1.2 Giới thiệu ISO 148 6.2 Cấu trúc level CMMI 149 6.2.1 Cấu trúc CMMI 149 PT IT 6.2.2 Các level CMMI 150 6.2.3 Việt Nam áp dụng CMM/CMMI lĩnh vực phần mềm 159 Tài liệu tham khảo 160 Phụ lục 161 Chương Khái niệm chất lượng phần mềm yếu tố chất lượng phần mềm 1.1 Đặc điểm phần mềm môi trường phát triển phần mềm Có thể nói phần mềm sản phẩm đặc biệt, khơng giống sản phẩm công nghiệp khác nên người ta thường gọi phát triển phần mềm Để phân biệt khác sản phẩm phần mềm với sản phẩm khác ta xem xét ba đặc điểm sau : (1) Độ phức tạp sản phẩm : Độ phức tạp sản phẩm đo số IT lượng phương thức vận hành sản phẩm Một sản phẩm cơng nghiệp chí máy tiên tiến không cho phép nhiều vài trăm phương thức vận hành Trong đó, gói phần mềm có tới hàng triệu khả vận hành Do đó, vấn đề đảm bảo vơ số khả vận hành xác định phát triển thách thức cơng nghiệp phần mềm PT (2) Tính trực quan sản phầm : Trong sản phẩm cơng nghiệp nhìn thấy được, sản phẩm phần mềm vơ hình Hầu hết nhược điểm sản phầm công nghiệp phát tiến trình sản xuất Hơn nữa, dễ dàng nhận thấy khuyết thiếu phần sản phẩm cơng nghiệp ( ví dụ : ơtơ khơng có cửa sổ ) Trái lại, nhược điểm sản phẩm phần mềm (được lưu trữ đĩa mềm hay CD) khơng nhìn thấy được, vậy, thực tế phẩn gói phần mềm thiếu từ đầu (3) Tiến trình sản xuất phát triển phần mềm : Các pha tiến trình sản xuất sản phẩm Phát triển sản phẩm : sản xuất công nghiệp, người thiết kế nhân viên đảm bảo chất lượng kiểm tra nguyên mẫu để phát khuyết điểm cuả chúng Trong sản xuất phần mềm, chuyên gia đảm bảo chất lượng đội phát triển có xu hướng tìm lỗi sản phẩm vốn có Kết cuối pha nguyên mẫu phê chuẩn, sẵn sàng để sản xuất Lập kế hoạch sản xuất sản phẩm : pha này, ngành cơng nghiệp, tiến trình sản xuất công cụ thiết kế chuẩn bị Một số dòng sản phẩm đặc biệt cần phải thiết kế xây dựng Do đó, pha tạo thêm hội xem xét sản phẩm, phát khuyết điểm bị người rà soát kiểm thử bỏ qua pha phát triển Ngược lại, pha khơng u cầu tiến trình sản xuất phần mềm, việc sản xuất copy phần mềm in sách hướng dẫn phần mềm thực tự động Điều áp dụng cho sản phẩm phần mềm nào, từ nhỏ tới lớn Sản xuất : Trong pha này, thủ tục đảm bảo chất lượng sản xuất công nghiệp áp dụng để phát lỗi sản xuất Các khuyết điểm sản phẩm phát giai đoạn trình sản xuất hiệu chỉnh thay đổi thiết kế sản phẩm nguyên liệu, hay cơng cụ sản xuất Nhờ tránh khuyết điểm sản phẩm sản xuất tương lai Ngược lại, nói phần trước, việc sản xuất phần mềm đơn giản chép sản phẩm in sách hướng dẫn, việc phát khuyết điểm sản phẩm khó khăn IT Kỹ nghệ phần mềm có bước phát triển đáng kể vượt qua nhiều giai đoạn khủng hoảng Những kết nghiên cứu kỹ nghệ phần mềm giúp tổ chức phát triển phần mềm cách chuyên nghiệp Môi trường phát triển phần mềm mang nét đặc trưng riêng Với bảy đặc trưng sau ta hiểu rõ mơi trường phát triển mơi trường bảo trì phần mềm chun nghiệp: PT (1) Các điều kiện hợp đồng : Là kết cam kết điều kiện hợp đồng nhà phát triển phần mềm khách hàng, họat động bảo trì phát triền phần mềm cần đương đầu với vấn đề : Một danh sách yêu cầu chức xác định mà phần mềm phát triển công việc bảo trì phải thực - Ngân sách dự án - Thời gian biểu dự án Nhà quản lý việc phát triển phần mềm bảo trì dự án cần nỗ lực lớn việc giám sát hoạt động để đạt yêu cầu hợp đồng (2) Mối quan hệ khách hàng – nhà cung cấp : Trong suốt trình phát triển bảo trì phần mềm, hoạt động nằm giám sát 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 yêu cầu thay đổi, để thảo luận khách hàng khơng lịng khía cạnh khách dự án, để đạt chấp thuận cho thay đổi theo sáng kiến đội phát triển (3) Yêu cầu làm việc theo nhóm : nhân tố thường thúc đẩy việc thành lập đội dự án thay giao dự án cho chuyên gia : Các yêu cầu thời gian biểu Nói cách khác, khối lượng cơng việc thực suốt thời kỳ dự án đòi hỏi tham gia nhiều người nều muốn dự án hoàn thành thời hạn - Để thực dự án cần có nhiều chuyên ngành khác - Sự rà soát lại hỗ trợ lẫn chuyên gia làm tăng chất lượng dự án (4) Hợp tác phối hợp với đội phần mềm khác : Để thực dự án, đặc biệt dự án có quy mơ lớn, cần nhiều đội dự án Đây điều phổ biến công nghiệp phần mềm Trong trường hợp 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 tổ chức - Các đội phát triển phần cứng tổ chức - Các đội phát triển phần cứng phần mềm nhà cung cấp khác IT Các đội phát triển phần cứng phần mềm khách hàng – người tham gia phần vào phát triển dự án PT (5) Các giao diện với hệ thống phần mềm khác : Ngày nay, hầu hết hệ thống phần mềm có giao diện với gói phần mềm khác Các giao diện cho phép liệu dạng điện tử “chảy” hệ thống phần mềm Có thể định nghĩa loại giao diện sau : Các giao diện đầu vào – nơi hệ thống phần mềm khác truyền liệu tới hệ thống phần mềm bạn Các giao diện đầu – nơi hệ thống phần mềm bạn truyền liệu xử lý tới hệ thống phần mềm khác Các giao diện đầu vào đầu tới bảng điều khiển máy, hệ thống kiểm sốt thí nghiệm 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 dự án thành viên đội có thay đổi : Việc thành viên đội rời khỏi đội thời gian phát triển dự án phổ biến, việc thăng chức với công việc cấp cao hơn, chuyển sang thành phố khác Người lãnh đạo đội phải thay thành viên đội nhân viên khác nhân viên tuyển dụng Không kể đến nỗ lực cần đầu tư vào việc đào tạo thành viên mới, việc thay đổi thành viên kéo theo thời gian thực dự án thay đổi (7) Sự cần thiết phải tiếp tục thực việc bảo trì phần mềm thời gian dài: Các khách hàng mua phát triển hệ thống phần mềm mong đợi tiếp tục sử dụng thời gian dài, thường từ 5-10 năm Trong suốt thời kỳ dịch vụ, cuối cần tới bảo trì Trong hầu hết trường hợp, dịch vụ bảo trì cần cung cấp trực tiếp nhà phát triển Trong trường hợp phần mềm phát triển “trong nhà”, khách hàng “nội bộ” chia sẻ vấn đề bảo trì phần mềm suốt thời kỳ dịch vụ hệ thống phần mềm 1.2 Khái niệm phần mềm Phần mềm bao gồm 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 vận hành hệ thống IT - Mỗi thành phần phần mềm có chức riêng chất lượng chúng đóng góp vào chất lượng chung phần mềm bảo trì phần mềm sau: PT Chương trình máy tính cần thiết hiển nhiên chúng giúp máy tính vận hành thực thi yêu cầu ứng dụng Những thủ tục yêu cầu để định nghĩa theo thứ tự lịch biểu chương trình thực thi, phương thức triển khai người chịu trách nghiệm cho thực thi hoạt động cần thiết cho việc tác động vào phần mềm Nhiều kiểu tài liệu cần thiết cho người phát triển, người sử dụng người có nhiệm vụ 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 phối hợp cộng tác hiệu thành viên đội ngũ phát triển hiệu việc xem lại rà soát cá sản phẩm lập trình thiết kế Tài liệu sử dụng(thường hướng dẫn sử dụng) cung cấp miêu tả cho ứng dụng sẵn sà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 thông tin yêu cầu mã nguồn công việc cấu trúc cho module Thông tin sử dụng để tìm nguyên nhân lỗi (bugs) thay đổi bổ sung thêm vào phần mềm có sẵn Dữ liệu bao gồm tham số đầu vào, mã nguồn danh sách tên thích hợp với phần mềm để đặc tả cần thiết cho người sử dụng thao tác với hệ thống Một kiểu khác liệu cần thiết chuẩn liệu test, sử dụng để sách định rõ thứ 10 Level : khởi đầu ( initial) Đây bước khởi đầu CMMI, trình thường hỗn độn hỗn loạn Tổ chức thường không cung cấp mơi trường ổn định Vì vậy, cơng ty hay doanh nghiệp, cá thể đạt level CMMI chưa yêu cầu tính  Đặc điểm :  Các hoạt động lực lượng lao động quan tâm hàng đầu thực cách hấp tấp vội vã  Đào tạo quản lý nhân lực nhỏ bé chủ yếu dựa vào kinh nghiệm cá nhân  Người quản lý mong phận nhân điều hành kiểm soát hoạt động lực lượng lao động  Các hoạt động lực lượng lao động khơng đáp ứng mà khơng cần phân tích ảnh hưởng  Doanh số thường xuyên thay đổi : nhân viên không trung thành với tổ chức PT IT  Đây điểm khởi đầu cho quy trình Nên tổ chức khơng có tiến hành cấu trúc Quy trình phần mềm tự phát triển hỗn độn khơng dự đốn trước Chất lượng phần mềm không biết Các doanh nghiệp sản xuất phần mềm dịch vụ thường bị vượt ngân sách dự thảo kế hoạch dự án Level : Lặp ( Repeatable) 152  Ở level người quản lý phải thiết lập nguyên tắc quản lý tất hoạt động diễn Họ phải có trách nhiệm phải quản lý đội ngũ Chúng gồm có : o Requirement Management (Lấy u cầu khách hàng, quản lý yêu cầu đó) o Software Project Planning (Lập kế hoạch cho dự án) o Project Monitoring and control (Theo dõi giám sát kiểm soát dự án) o Measurement and analysis (Đo lường phân tích) o Software Configuration Management (Quản trị cấu hình sản phẩm => yêu cầu khách hàng không) o Process and product quality assurance (đảm bảo trình chất lượng sản phẩm)  Mức 2, có đặc điểm đặc trưng sau : PT IT o Goal (mục tiêu): hoạt động đề xuất dự án phần mềm phải lên kế hoạch viết tài liệu đầy đủ o Commitment (đề xuất/xem xét): dự án phải tuân thủ theo qui tắc tổ chức hoạch định o Ablility (Khả năng): Việc thực lập kế hoạch cho dự án phần mềm phải bước thực từ sớm dự án bắt đầu o Measument (Đo lường ): Sự đo lường thực thi sử dụng ln xác định kiểm sốt tình trạng hoạt động tiến trình thực dự án o Verification (Kiểm chứng ): Các hoạt động lập kế hoạch dự án phải kiểm tra lại quản lý cấp cao  Để đạt level 2, tổ chức phải đạt tất mục tiêu cụ thể level Dự án tổ chức phải đảm bảo yêu cầu quản lý quy trình lên kế hoạch, thực hiện, đánh giá kiểm soát Ở level này, tất yêu cầu, quy trình, sản phẩm quản lý Tại thời điểm xác định thấy tình trạng dự án Các quy trình quản lý dự án thiết lập giá thành, kế hoạch chức Sản phẩm phải đáp ứng yêu cầu, quy định, tiêu chuẩn mục tiêu 153 Các KPAs cần trọng tới thành phần: o o o o o o Chế độ đãi ngộ Đào tạo Quản lý thành tích Phân công lao động Thông tin giao tiếp Môi trường làm việc Để từ level tiến tới level ta cần có nh ng điều kiện sau : Trước hết ta cần phải thỏa mãn điều kiện level Cần ý tới yếu tố sau : Môi trường làm việc: IT  PT o Đàm bảo điều kiện làm việc o Tạo hứng thú công việc o Không bị ảnh hưởng, gây tập trung yếu tố khác  Thông tin: Xây dựng chế truyền thông tin suốt từ xuống ngược lại nhằm giúp cá nhân tổ chức chia sẻ thông tin, kiến thức, kinh nghiệm, kỹ giao tiếp phối hợp làm việc hiệu  Xây dựng đội ngũ nhân viên: Ngay từ khâu tuyển dụng, cần lựa chọn kỹ càng, định hướng, thể chế hóa quy trình tuyển dụng  Quản lý thành tích: Cần đẩy mạnh thành tích, cơng nhận lực, thành tích cách thiết lập tiêu chí khách quan để đánh giá liên tục khuyến khích khả làm việc, tập trung phát triển nghiệp, xây dựng mục tiêu  Đào tạo : Không đào tạo kiến thức chuyên môn phục vụ cho dự án mà mở rộng đào tạo kỹ then chốt, cần thiết kĩ làm việc nhóm, kỹ 154 quản lý nhằm tạo hội cho nhân viên phát huy hết khả có hội hỏi, phát triển thân  Chế độ đãi ngộ: Hoạch định chiến lược đãi ngộ, thu thập ý kiến lực lượng lao động công bố công khai Chế độ đãi ngộ cần tập trung vào việc trả lương cho công nhân viên dựa vào vai trị, vị trí họ (Position), Con người (Person) – thái độ tác phong làm việc thành tích (Performance) mà họ đạt được, cống hiến cho tổ chức Đưa sách lương, thưỏng, phụ cấp quyền lợi khác để khuyến khích cá nhân dựa đóng góp họ cấp độ phát triển toàn tổ chức Level : Xác lập (Defined ) IT Các vùng tiến trình chủ chốt mức nhằm vào hai vấn đề dự án tổ chức Các tiêu chuẩn, quy trình, thủ tục cho dự án thiết kế riêng từ tổ chức với quy trình tiêu chuẩn cho phù hợp với dự án cụ thể Quy trình phần mềm cho hoạt động quản lý sản xuất tài liệu hóa tích hợp vào quy trình phần mềm chuẩn nhà sản xuất Level tập trung vào yếu tố sau: o o o o o o o o o  PT  Requirements Development (Phát triển yêu cầu) Technical Solution (Giải pháp kĩ thuật) Product Integration (Tích hợp sản phẩm) Organizational Process Focus (Tập trung tiến trình tổ chức) Organizational Process Definition (Phân định tiến trình tổ chức) Organizational Training (Tổ chức đào tạo) Integrated Project Management (Quản lý tích hợp dự án) Risk Management (Quản lý rủi ro) Decision Analysis and Resolution (Phân tích định giải pháp) Để đạt level tổ chức phải nắm rõ hiểu quy trình miêu tả tiêu chuẩn, phương pháp Người quản lý phải biến đổi cải tiến hoạt động diễn ra, cải tiến môi trường làm việc 155  Ở level 3, tổ chức phải đạt tất mục tiêu cụ thể , yêu cầu cụ thể mức  KPA trọng tới yếu tố sau : o o o o o Văn hóa cá thể Cơng việc dựa vào kỹ Phát triển nghiệp Hoạch định nhân Phân tích kiến thức kỹ Từ level đến level KPA cần thực : Phân tích kiến thức kĩ : IT   PT Xác định kỹ kiến thức cần thiết để làm tảng cho hoạt động nhân Lĩnh vực phân tích bao gồm: xác định quy trình cần thiết để trì lực tổ chức, phát triển trì kỹ kiến thức phục vụ công việc, dự báo nhu cầu kiến thức kỹ tương lai Hoạch định nguồn nhân lực : Đây lĩnh vực phối hợp hoạt động nhân với nhu cầu tương lai cấp toàn tổ chức Hoạch định nguồn nhân lực có tính chiến lược với quy trình theo dõi chặt chẽ việc tuyển dụng hoạt động phát triển kỹ tạo nên thành cơng việc hình thành đội ngũ  Phát triển nghiệp : Tạo điều kiện cho cá nhân phát triển nghề nghiệp có hội thăng tiến nghề nghiệp, bao gồm: xác định hội, theo dõi tiến cơng việc, khuyến khích đạt mục tiêu công việc  Các hoạt động dựa lực : 156 Ngoài kỹ năng, kiến thức cốt lõi cịn có hoạch định nhân lực, tuyển dụng dựa vào khả làm việc, đánh giá hiệu qua cơng việc vị trí, xây dựng chế độ ưu đãi dựa hiệu đạt đảm bảo hoạt động tổ chức xuất phát từ mục đích phục vụ cho phát triển nhân lực  Văn hóa cá thể : Tạo lập chế độ thông tin liên lạc thông suốt, kênh thông tin hiệu cấp độ tổ chức, phối hợp kinh nghiệm, kiến thức người để hỗ trợ lẫn nhau, thúc đẩy nhân viên tham gia ý kiến Level : Kiểm soát (Quantitatively Managed)  Thực đo lường chi tiết quy trình phần mềm chất lượng sản phẩm Mục tiêu định lượng chất lượng hiệu suất trình sử dụng tiêu chuẩn trình quản lý IT  Mục tiêu định lượng dựa nhu cầu khách hàng, người dùng, tổ chức trình dự án Chất lượng hiệu suất dự án thống kê quản lý suốt trình dự án PT  Các vùng tiến trình chủ yếu mức tập trung vào thiết lập hiểu biết định lượng trình sản xuất phần mềm sản phẩm phần mềm xây dựng Đó là: o Quantitative Project Management (Quản lý định lượng dự án) o Organizational Process Performance (Tổ chức trình hiệu suất)  Lực lượng lao động làm việc theo đội, nhóm quản lý cách định lượng  Các KPA level trọng tới: o o o o o Chuẩn hóa thành tích tổ chức Quản lý lực tổ chức Công việc dựa vào cách làm việc theo nhóm Xây dựng đội ngũ chuyên nghiệp Cố vấn 157  Để đạt level phải đo lường chuẩn hóa Đo lường hiệu đáp ứng cơng việc, chuẩn hóa phát triển kỹ năng, lực cốt lõi  Sự khác level level khả đoán trước việc thực quy trình Tại level 4, việc thực quy trình kiểm sốt tiêu chuẩn định lượng kỹ thuật định lượng đốn trước Tại level 3, quy trình đoán chất lượng Level : Tối ưu (Optimizing) Các quy trình mức liên tục cải tiến dựa ý kiến phản hồi từ việc sử dụng quy trình, thí điểm ý tưởng quản lý cơng nghệ Đó là: o Causal Analysis and Resolution (Phân tích nguyên nhân giải pháp) o Organizational Innovation and Deployment (Tổ chức cải tiến triển khai)  Level tập trung vào cải thiện liên tục thực trình suốt PT IT  trình phát triển, đổi cơng nghệ Q trình phát triển chất lượng đối tượng tổ chức thiếp lập, tiếp tục duyệt lại để phản ánh thay đổi đối tượng kinh doanh sử dụng tiêu chuẩn trình phát triển quản lý Tối ưu trình nhanh nhẹn, thích hợp đổi định dựa tham gia lực lượng lao động theo giá trị kinh doanh đối tượng tổ chức  Ngồi ra, level cịn trọng vào việc quản lý, phát triển lực nhân viên Huấn luyện nhân viên trở thành chuyên gia  Khoảng cách level level dạng biến đổi trình Tại level 4, quy trình có liên quan tới địa đặc biệt biến đổi quy trình điều kiện tiêu chuẩn đốn trước kết suốt q trình, thủ tục đốn kết quả, kết không đạt việc thiết lập đối tượng level5, quy trình liên quan đến nhiều địa 158 chia sẻ trình thay đổi để phát triển thực trình giành thiết lập định lượng cho trình phát triển đối tượng 6.2.3 Việt Nam áp dụng CMM/CMMI lĩnh vực phần mềm Hiện nay, công ty, doanh nghiệp Việt Nam đua lấy chứng nhận ISO CMMI Bởi họ muốn cải tiến trình quản lý việc phát triển phần mềm theo nhu cầu khách hàng để quảng cáo Tất nhận thức vấn đề ISO CMMI thực đem lại lợi ích dài lâu cho tổ chức, cơng ty họ IT Về bản, quản lý chất lượng phần mềm vấn đề khơng mới, lại vấn đề cịn yếu cơng ty phần mềm Việt Nam Một số công ty đạt chuẩn quốc tế CMM/CMMI nâng cao lực quản lý chất lượng phần mềm, song gói gọn vài cơng ty gia cơng cho nước ngồi PT Và thời điểm nay, có nhiều doanh nghiệp phần mềm áp dụng mơ hình đánh giá lực sản xuất phần mềm CMM/CMMI Việt Nam Đây số công ty, doanh nghiệp đạt chứng Ví dụ FPT Software (CMM mức 5), CMC soft đạt yêu cầu tiêu tiêu chuẩn Việt Nam ISO 9001 : 2008 CMMI mức 3, PSV (CMMi mức 5), GCS (CMMI mức 4), Và gần vào ngày 26/02/2013, Global CyberSoft (Việt Nam) đạt chuẩn CMMI Mức 5, phiên 1.3 Tháng 9/2011, VNPT Hải Phòng đạt chuẩn CMMI mức 159 Tài liệu tham khảo [1] Daniel Galin, Software Quality Assurance – From Theory to Implemtation, Addion Wesley, 2004 [2] Ian Sommerville Software Engineering, Sixth Edition, Addion Wesley, 2001 [3] Gerald D Everett, Raymond McLeod, Jr., Software Testing Testing Across the Entire Software Development Life Cycle, IEEE press, Wiley-interscience , A John Wiley&Sons, Inc, Publication, 2007 [4] Glenford J Myers The Art of Software Testing - Second Edition John Wiley & Sons, Inc, Publication, 2004 IT [5] Tạp chí khoa học “thực tiễn việc khai triển chuẩn CMMI cho doanh nghiệp gia công phân mềm Việt Nam” khoa kinh tế, Đại Học Quốc Gia Hà Nôi [6] http://cmmiinstitute.com [7] http://www.tutorialspoint.com/cmmi/cmmi-maturity-levels.htm PT Chương [8] Bộ chuẩn CMMI5 FPT 160 Phụ lục Một số lỗi thường mắc phải trình phát triển phần mềm, đặc biệt pha cài đặt trích từ sách “The art of software testing” cho Lỗi tham chiếu - Data reference Error Biến tham chiếu gán giá trị trước khởi tạo? Đây lỗi thường xảy Với truy cập mảng, số có nằm biên cho phép hay khơng? Với truy cập mảng, số có nhận giá trị nguyên hay không? Với tham chiếu dùng trỏ biến tham chiếu, ô nhớ tham chiếu xác IT định chưa? Đây gọi “dangling reference” Nó xảy thời gian tồn trỏ dài thời gian tồn ô nhớ tham chiếu Trường hợp khác trỏ tham chiếu tới biến địa phương hàm, giá trị trỏ gán cho tham số bên ngồi, biến tồn cục, hàm kết thúc (giải phóng nhớ tham chiếu), sau chương trình dùng giá trị trỏ PT Khi đặt nhiều tên (alias) cho vùng nhớ với thuộc tính khác , liệu giá trị liệu vùng nhớ có thuộc tính tham chiếu theo tên? Ví dụ, chương trình FORTRAN chưa biến thực A nguyên B; biến alias cho vùng nhớ sử dụng câu lệnh EQUIVALENCE Nếu chương trình lưu giá trị vào A sau truy cập tới biến B; lỗi xuất máy tính dùng biểu diễn số floating point nhớ số nguyên Liệu giá trị biến có kiểu thuộc tính khác với trình biên dịch đặt ra? Tình xảy chương trình C, C++ đọc ghi vào nhớ truy cập tới thơng qua cấu trúc, nhiên biểu diễn vật lý ghi khác với định nghĩa cấu trúc Vấn đề địa chỉ? liệu đơn vị vùng nhớ cấp phát máy tính chạy có nhỏ đơn vị vùng nhớ định nghĩa Ví dụ, với số mơi trường, xâu bit có độ dài cố định không cần bắt đầu byte biên, địa chỉ tới byte biên Nếu chương trình tính địa xâu bit sau tham chiếu tới xâu thơng qua địa này, ta truy cập vào vùng nhớ khơng xác Tình xảy truyền đối số xâu bit cho chương trình Nếu biến trỏ biến tham chiếu dùng, liệu vùng nhớ tham chiếu có thuộc tính trình biên dịch mong muốn? Một ví dụ lỗi trỏ C++ 161 trỏ tới địa cấu trúc liệu khác với cấu trúc liệu Nếu cấu trúc liệu tham chiếu nhiều hàm, thủ tục, liệu cấu trúc có định nghĩa thống thủ tục không? Khi đánh số cho xâu/mảng, liệu có giới hạn số kết thúc xâu/mảng phạm vi cho phép khơng? Với ngơn ngữ lập trình hướng đối tượng, liệu tất yêu cầu thừa kế có thoả mãn cài đặt class? Lỗi khai báo d liệu (Data-Declaration Errors ) IT Liệu biến có khai báo xác? Một failure trường hợp khơng phải lỗi, khởi nguồn cho nhiều vấn đề Ví dụ, hàm nhận tham số mảng, không định nghĩa tham số mảng thành công, tham chiếu tới mảng (ví dụ C=A(I) dịch thành lời gọi hàm, dẫn tới máy tính cố gắng thực mảng chương trình Thêm nữa, biến không định nghĩa cách rõ ràng thủ tục, khối lệnh, liệu ta hiểu biến dùng chung hay khơng? ) PT Nếu tất thuộc tính biến khơng quy định rõ ràng lúc định nghĩa, liệu giá trị mặc định có hiểu rõ? Ví dụ, thuộc tính mặc định nhận Java thường nguồn ngạc nhiên lớn Khi biến khởi tạo câu lệnh khai báo, liệu có khởi tạo đúng? Trong nhiều ngôn ngữ, khởi tạo mảng xâu đơi phức tạp có xu hướng gây lỗi Liệu biến có gán với độ dài kiểu? Liệu khởi tạo biến có đồng với kiểu memory? Ví dụ, biến hàm FORTRAN cần khởi tạo lại lần gọi hàm, phải khửoi tạo câu lệnh gán câu lệnh DATA Liệu có tên biến tương tự (ví dụ VOLT VOLTS)? Đây không thiết lỗi, ta nên đặt tên khác phịng nhầm lẫn Lỗi tính tốn (Computation Errors) Liệu có tính tốn sử dụng biến với kiểu liệu khơng phù hợp? Liệu có tính tốn mixed-mode (kết hợp kiểu) khơng? Ví dụ cộng biến floating point 162 cho biến integer Cần hiểu rõ luật chuyển đổi kiểu để tránh sai sót Ví dụ, đoạn mã Java sau có lỗi rouding (làm trịn) thực với số integers int x=1; int y=2; int z=0; z=x/y; System.out.println ("z="+z); OUTPUT: z = Liệu có tính tốn sử dụng biến có kiểu độ dài khác nhau? Liệu kiểu biến đích phép gán nhỏ kiểu kết biểu thức vế phải? IT Liệu có xảy lỗi overflow underflow (tràn) tính tốn biểu thức? Chẳng hạn, kết giá trị hợp lệ, kết trung gian lớn nhỏ so với kiểu cho phép ngôn ngữ lập trình Liệu có phép thực chia cho 0? PT Nếu máy biểu diễn biến số nhị phân, liệu có chuỗi tính tốn cho kết sai hay không? Chẳng hạn, 10 x 0.1 không 1.0 thực số nhị phân Khi đưa vào ứng dụng, liệu giá trị biến có ngồi khoảng có nghĩa Với biểu thức chứa nhiều phép toán, liệu giả thiết thứ tự ưu tiên phép tốn có xác? Có phép tốn khơng hợp lệ liên quan tới số integer không, đặc biệt phép chia? Ví dụ, i biến integer, biểu thức 2*i/2 == i phụ thuộc vào i số chẵn hay lẻ phép nhân hay chia thực trước? Lỗi so sánh (Comparison Errors) Có phép so sánh biến với kiểu khác khơng, ví dụ so sánh xâu kí tự với địa chỉ, ngày, số? Liệu có so sánh mixed-mode không so sánh biến với độ dài khác nhau? Nếu có, cần đảmm bảo luật biến đổi phải hiểu xác Các phép so sánh có xác? Lập trình viên thường bị nhầm quan hệ 163 at most, at least, greater than, not less than, less than or equal Liệu biểu thức Boolean có giá trị mong đợi? Lập trình viên thường mắc lỗi viết biểu thức logic chứa and, or, not Liệu toán hạng phép tốn Boolean có giá trị Boolean? Phép so sánh phép toán Booleans thường dùng xen kẽ Hành động dễ dẫn tới lỗi Ví dụ, ta cần xác định i có nằm khoảng từ tới 10 hay không, biểu thức < i < 10 sai; biểu thức (2x)||(i>y) Nếu ta muốn so sánh số có hay khơng, biểu thức (a==b==c) cho kết khác với mong đợi Nếu muốn kiểm tra quan hệ x>y>z, biểu thức phải (x>y)&&(y>z) Liệu có phép so sánh số phẩy tĩnh số phẩy động (floating point) hệ số 2? Đây nguồn lỗi lỗi làm tròn biểu diễn xấp xỉ số số hệ số 10 IT Với biểu thức chứa nhiều phép toán boolean, quy ước thứ tự thực phép tốn có xác? Ví dụ, với biểu thức (if((a==2) && (b==2) || (c==3)), phép and hay or thực trước cần quy định rõ ràng PT Liệu cách thức trình biên dịch tính tốn giá trị biểu thức Boolean có ảnh hưởng tới chương trình? Ví dụ, câu lệnh : if((x==0 && (x/y)>z) chấp nhận với trình biên dịch kết thúc kiểm tra điều kiện vế and false, dẫn tới lỗi division-by-zero (chia cho 0) với trình biên dịch khác Lỗi luồng điều khiển (Control-Flow Errors) Nếu chương trình chứa nhánh nhiều hướng, chẳng hạn phép tính GO TO, liệu biến số có ngồi phạm vi nhánh? Ví dụ câu lệnh GO TO (200, 300, 400), i liệu i có nằm số giá trị 1, 2, 3? Liệu vịng lặp có kết thúc? Chứng minh vịng lặp kết thúc Chương trình, module, hàm có kết thúc? 164 Với vịng lặp điều khiển biểu thức điều kiện (ví dụ vịng lặp tìm kiếm), iteration, what are the consequences of loop fall-through? Ví dụ, với giả mã: DO I=1 to TABLESIZE WHILE (NOTFOUND) chuyện xảy NOTFOUND không false? Lỗi giao diện (Interface Errors) Liệu số tham số module có với số đối số lời gọi hàm Liệu thứ tự đối số có xác? Liệu thuộc tính (chẳng hạn kiểu liệu, kích thước) tham số có tương thích với thuộc tính đối số tương ứng? Liệu đơn vị tham số có tương thích với đơn vị đối số tương ứng? Ví dụ, tham số dùng đơn vị degrees, đối số lại dùng đơn vị radians? IT Liệu số đối số truyền module cho module khác có số tham số expected by that module? Nếu hàm built-in gọi, liệu số, thuốc tính thứ tự đối số có xác? PT Lỗi Input/Output Nếu files định nghĩa, liệu thuộc tính có xác? Liệu thuộc tính câu lệnh OPEN file có xác? Liệu định dạng file có khớp với câu lệnh I/O? Có đủ nhớ để chứa file mà chương trình đọc? Các files mở trước dùng? Các files đóng sau dùng? Điều kiện end-of-file có phát quản lý xác? Các điều kiện lỗi I/O quản lý xác? Các xuất lỗi tả, cú pháp đoạn văn có in/hiển thị ? Các kiểm tra khác 165 Nếu trình biên dịch đưa danh sách thuộc tính, kiểm tra thuộc tính biến để đảm bảo khơng có thuộc tính mặc định khơng mong muốn gán giá trị Nếu chương trình dịch thành cơng, máy tính đưa cảnh báo (“warning”), ta cần kiểm tra chúng cẩn thận Cảnh báo ám trình biên dịch phát bạn làm việc gây nghi vấn Các nghi vấn cần kiểm tra lại PT IT Liệu chương trình hay module có kiểm tra validity cho đầu vào 166 ... tiêu đảm bảo chất lượng phần mềm Phát triển phần mềm ln đơi với bảo trì, hoạt động bảo đảm chất lượng phần mềm có mối liên quan chặt chẽ đến bảo trì Những mục tiêu đảm bảo chất lượng phần mềm. .. phần mềm 11 1.4 Định nghĩa chất lượng phần mềm đảm bảo chất lượng phần mềm 14 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 yếu tố chất. .. niệm chất lượng phần mềm yếu tố chất lượng phần mềm PT Những khái niệm mở đầu tài liệu giới thiệu chương Bắt đầu với khái niệm phần mềm, chất lượng phần mềm đảm bảo chất lượng phần mềm, phần