Tài liệu Kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm

ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ _ TRỊNH THỊ LÌNH KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM LUẬN VĂN THẠC SĨ Hà Nội – 2011 ĐẠI HỌC QUỐC GIA HÀ NỘI TRƯỜNG ĐẠI HỌC CÔNG NGHỆ TRỊNH THỊ LÌNH KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM Ngành: Công nghệ thông tin Chuyên ngành: Công nghệ phần mềm Mã số: 60 48 10 LUẬN VĂN THẠC SĨ NGƯỜI HƯỚNG DẪN KHOA HỌC: TS Nguyễn Trường Thắng Hà Nội – 2011 3 MỤC LỤC DANH MỤC CHỮ VIẾT TẮT .......................................................................................5 LỜI MỞ ĐẦU ............................................................................................................6 CHƯƠNG I: NỀN TẢNG LÝ THUYẾT.........................................................................8 1.1. Quy trình phát triển phần mềm ....................................................................................... 8 1.1.1. Khái niệm ................................................................................................................. 8 1.1.2. Một số mô hình phát triển ......................................................................................... 8 1.1.3. Mô hình phân tầng (layer) .......................................................................................11 1.1.4. Lập trình hướng đối tượng.......................................................................................12 1.2. Chất lượng phần mềm....................................................................................................13 1.2.1. Khái niệm ................................................................................................................13 1.2.2. Đảm bảo chất lượng phần mềm (SQA_ Software Quality Assuarance) .....................14 1.2.3. Chuẩn phần mềm.....................................................................................................23 1.2.4. Kiểm soát chất lượng phần mềm ..............................................................................23 CHƯƠNG II: MỘT SỐ KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM ................................................................................................................................26 2.1. Đánh giá.........................................................................................................................26 2.2. Tổ chức môi trường làm việc..........................................................................................28 2.2.1. Làm việc nhóm ........................................................................................................28 2.2.2. Quy ước lập trình ....................................................................................................29 2.3. Mô đun hóa các chức năng ............................................................................................30 2.4. Kỹ thuật kiểm thử ...........................................................................................................31 2.4.1. Kiểm thử đơn vị .......................................................................................................32 2.4.2. Kiểm thử tích hợp ....................................................................................................32 2.4.3. Kiểm thử chấp nhận.................................................................................................33 2.4.4. Kiểm thử hồi quy .....................................................................................................33 4 2.4.5. 2.5. Danh sách lỗi và chức năng bổ sung ........................................................................33 Kỹ thuật hỗ trợ kiểm soát phiên bản...............................................................................36 2.5.1. Một số đặc điểm cơ bản của công cụ kiểm soát phiên bản SVN ................................36 2.5.2. Vòng đời làm việc điển hình là: ..............................................................................39 CHƯƠNG III: ỨNG DỤNG THỰC TIỄN ..................................................................41 3.1. Giới thiệu về dự án V.EMIS ...........................................................................................41 3.2. Môi trường làm việc .......................................................................................................42 3.2.1. Tổ chức môi trường làm việc ...................................................................................42 3.2.2. Quy ước lập trình ....................................................................................................44 3.3. Thực hiện mô đun hóa các chức năng ...........................................................................48 3.4. Kết quả khi áp dụng kỹ thuật kiểm thử ..........................................................................51 3.5. Áp dụng kỹ thuật kiểm soát phiên bản ...........................................................................54 KẾT LUẬN................................................................................................................61 TÀI LIỆU THAM KHẢO .............................................................................................63 5 DANH MỤC CHỮ VIẾT TẮT Chữ viết tắt Tiếng Anh Tiếng Việt CMM Capability Maturity Model Mô hình thuần thục khả năng CMMI Capability Maturity Model Integration Mô hình thuần thục khả năng tích hợp CSDL Database Cơ sở dữ liệu IEEE Institute Electrical and Electronic Engineers Institute Electrical and Electronic Engineers ISO International Standards Organization Tổ chức chuẩn Quốc tế VCS Version control system Hệ thống kiểm soát phiên bản QA Quality Assuarance Đảm bảo chất lượng QC Quality control Kiểm soát chất lượng SLC Software life cycle Vòng đời phát triển phần mềm SQA Software Quality Assuarance Đảm bảo chất lượng phần mềm SQAP Software Quality Assuarance Plan Kế hoạch đảm bảo chất lượng phần mềm SQC Software Quality Control Kiểm soát chất lượng phần mềm SVN Subversion Subversion V&V Verification and Validation Xác minh và thẩm định 6 LỜI MỞ ĐẦU Trong xã hội công nghệ thông tin ngày càng phát triển kéo theo ngành công nghệ phần mềm cũng phát triển. Yêu cầu đặt ra đối với chất lượng mỗi sản phẩm phần mềm trở nên nghiêm ngặt. Trong khi đó, quy trình phát triển phần mềm được thực hiện với nhiều giai đoạn khác nhau và với rất nhiều hoạt động khác nhau. Mỗi giai đoạn đều giữ một vai trò nhất định để góp phần xây dựng nên một phần mềm đảm bảo chất lượng theo như chuẩn đảm bảo chất lượng. Một trong những vai trò rất quan trọng đó là hoạt động kiểm soát chất lượng phần mềm. Nhiệm vụ chính là kiểm soát xem phần mềm có đảm bảo yêu cầu chất lượng đặt ra hay không, các kiểm thử có đáp ứng yêu cầu không? Ngày nay, các yếu tố về chất lượng (Quality), chi phí (Cost) và thời hạn (Delivery) thường được coi là 3 tiêu chí căn bản nhất cho sự thành công của một sản phẩm nói chung và sản phẩm phần mềm nói riêng. Như vậy, để tạo ra một sản phẩm phần mềm có chất lượng thì hoạt động kiểm tra phần mềm đóng vai trò rất quan trọng, trong khi đó hoạt động này lại tiêu tốn nhiều chi phí và chiếm tỷ trọng khá lớn về công sức, thời gian trong một dự án. Do đó một yêu cầu thực tiễn rất cấp thiết là đội dự án phải có kế hoạch để đảm bảo phần mềm sản xuất ra có chất lượng trong khi chi phí thấp. Chất lượng phần mềm luôn được kiểm soát trong suốt quá trình sản xuất, từ lúc nhận yêu cầu cho đến khi sản phẩm đưa vào sử dụng, trong thời gian sử dụng cho đến khi sản phẩm phần mềm đó lỗi thời hoặc có phần mềm khác thay thế. Kiểm soát chất lượng phần mềm là quá trình giúp sớm phát hiện khiếm khuyết để từ đó sớm đi đến khắc phục những khiếm khuyết của phần mềm trong suốt quá trình phát triển. Phát hiện lỗi và khắc phục lỗi sớm giúp giảm bớt phát sinh lỗi mới và dẫn đến chi phí cho sửa chữa cũng giảm bớt, nâng cao chất lượng cho phần mềm. Cơ sở để đánh giá chất lượng phần mềm là: phần mềm khi phát triển phải đáp ứng các yêu cầu đặt ra cũng như kỳ vọng của khách hàng và của bản thân nhà sản xuất. Để đánh giá quy trình kiểm soát chất lượng phần mềm, người ta dựa vào bộ chuẩn. Ví dụ như các bộ chuẩn quốc tế ISO, CMM, CMMI, IEEE…. Đáp ứng điều đó thì nhiều kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm ra đời nhằm kiểm soát quá trình phát triển phần mềm của các đội dự án sao cho phần mềm sản xuất ra đảm bảo chất lượng theo như yêu cầu và mong muốn của khách hàng cũng như người sử dụng sản phẩm đó. Thấy được tầm quan trọng trong vấn đề kiểm soát chất lượng nên trong khóa luận này tôi thực hiện nghiên cứu về một số “Kỹ thuật hỗ trợ việc kiểm soát chất lượng phần mềm”. Trong thực tế, một phần mềm tốt thì thời gian sống phải dài. Sản phẩm phần mềm phải liên tục tiến hóa sau khi bàn giao. Phần mềm mà không có sự tiến hóa là 7 phần mềm chết. Điều đó đồng nghĩa với chất lượng phần mềm kém, ít người sử dụng thậm chí không có người sử dụng. Một ví dụ điển hình là Windows đã tiến hóa trong 20 năm qua, nó gặp phải nhiều lỗi và liên tục sửa chữa, nâng cấp để tạo các phiên bản mới nhưng vẫn được đông đảo người sử dụng. Thách thức lớn nhất đối với các đơn vị phát triển phần mềm là sự không ổn định trong yêu cầu của người dùng. Ngoài ra, phần mềm phải triển khai trên quy mô lớn mới bộc lộ hết được những khiếm khuyết về chức năng, lôgic trong chương trình do có nhiều người sử dụng khác nhau. Sản phẩm vừa phát triển với tính năng mới lại vừa sửa lỗi cũ trong khi triển khai quy mô lớn đó là tình huống khó nhất khi phát triển phần mềm. Windows là một ví dụ điển hình. Kỹ thuật phát triển phần mềm và kiểm soát chất lượng trong những hoàn cảnh như vậy là cả một khoa học và công nghệ làm phần mềm, đòi hỏi kinh nghiệm thực tế và lý thuyết về công nghệ phần mềm. Vì vậy, khi phần mềm sản xuất muốn đảm bảo chất lượng tốt thì phải luôn được kiểm soát chặt chẽ. Nội dung chính được trình bày trong khóa luận: Chương I: Nền tảng lý thuyết Giới thiệu một số kiến thức có liên quan như: quy trình phát triển, chất lượng phần mềm, đảm bảo chất lượng phần mềm, kiểm soát chất lượng phần mềm…. giúp có cái nhìn sơ bộ về những vấn đề có liên quan đến quá trình phát triển phần mềm đảm bảo chất lượng. Chương II: Một số kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm Nghiên cứu một số kỹ thuật hỗ trợ quá trình kiểm soát chất lượng phần mềm. Với những kỹ thuật hỗ trợ kiểm soát chất lượng sẽ làm cho sản phẩm phần mềm tạo ra có chất lượng cao. Với những kỹ thuật được đề cập đến sẽ giúp giải quyết tình huống khó khăn nhất trong phát triển phần mềm: phần mềm luôn thay đổi, vừa thực hiện triển khai vừa phát triển. Chương III: Ứng dụng vào thực tiễn của đội dự án - Phân tích môi trường phát triển - Thực hiện mô đun hóa các chức năng - Áp dụng một số kỹ thuật hỗ trợ kiểm soát chất lượng vào quá trình phát triển phần mềm. 8 CHƯƠNG I: NỀN TẢNG LÝ THUYẾT 1.1. Quy trình phát triển phần mềm 1.1.1. Khái niệm Quy trình phát triển phần mềm là tập các giai đoạn và các kết quả tương quan để sản xuất ra một sản phẩm phần mềm. Quy trình là một trong những yếu tố cực kỳ quan trọng đem lại sự thành công cho các nhà sản xuất phần mềm, nó giúp cho mọi thành viên trong dự án từ người cũ đến người mới, trong hay ngoài công ty đều có thể xử lý đồng bộ công việc tương ứng vị trí của mình thông qua cách thức chung của công ty, hay ít nhất ở cấp độ dự án. Hầu hết các thao tác này được tiến hành bởi các kỹ sư phần mềm. Có 4 giai đoạn là nền tảng của hầu hết các quy trình phần mềm là:  Đặc tả phần mềm: Các chức năng của phần mềm và điều kiện để nó hoạt động phải được định nghĩa.  Phát triển phần mềm: Để phần mềm đạt được đặc tả thì phải có quy trình phát triển này.  Đánh giá thẩm định phần mềm: Phần mềm phải được đánh giá để chắc chắn rằng nó thực hiện đúng những gì mà khách hàng mong muốn.  Tiến hóa của phần mềm: Phần mềm phải tiến hóa để thỏa mãn sự thay đổi các yêu cầu của khách hàng. 1.1.2. Một số mô hình phát triển Có nhiều mô hình phát triển phần mềm: mô hình thác nước, mô hình chữ V, mô hình tiến hóa, mô hình mẫu, mô hình xoắn ốc, mô hình CMM/CMMI. Mỗi mô hình phát triển có những đặc điểm và ưu nhược điểm riêng, nó phù hợp với từng loại dự án. Nên tùy theo dự án mà người quản lý dự án chọn cho mình mô hình phát triển riêng, phù hợp với đặc điểm của dự án. Đặc điểm và ưu nhược điểm của mỗi mô hình phát triển được thể hiện như sau: 9 Mô hình thác nước Xác định yêu cầu hệ thống Kiểm chứng Xác địnhYêu yêu cầu cầu phần mềm Kiểm chứng cấp phát Thiết kế căn bản Kiểm chứng Thiết kế chi tiết Kiểm thử Lập trình Kiểm chứng Kiểm thử Kiểm chứng Vận hành, bảo trì Hình 1.1: Mô hình thác nước Mô hình này làm cho ý nghĩa việc sản xuất phần mềm được thấy rõ hơn: 1. Phân tích các yêu cầu và định nghĩa: hệ thống dịch vụ, khó khăn và mục tiêu được hình thành bởi sự trợ ý của hệ thống người tiêu dùng. Sau đó các yếu tố này được định nghĩa sao cho có thể hiểu được bởi cả người phát triển và người tiêu dùng. 2. Thiết kế phần mềm và hệ thống: Thiết kế hệ thống các quy trình, các bộ phận và các yêu cầu về cả phần mềm lẫn phần cứng. Hoàn tất hầu như tất cả kiến trúc của các hệ thống này. Thiết kế phần mềm tham gia vào việc biểu thị các chức năng hệ thống phần mềm mà có thể được chuyển dạng thành một hay nhiều chương trình khả thi. 3. Thực hiện và thử nghiệm các đơn vị: Trong giai đoạn này, thiết kế phần mềm phải được chứng thực như là một tập hợp nhiều chương trình hay nhiều đơn vị nhỏ. Thử nghiệm các đơn vị bao gồm xác minh rằng mỗi đơn vị thỏa mãn đặc tả của nó. 10 4. Tổng hợp và thử nghiệm toàn bộ: Các đơn vị chương trình riêng lẻ hay các chương trình được tích hợp lại và thử nghiệm như là một hệ thống hoàn tất và chứng tỏ được các yêu cầu của phần mềm được thỏa mãn. Sau khi thử nghiệm phần mềm được cung ứng cho người tiêu dùng. 5. Sản xuất và bảo trì: Thông thường (nhưng không bắt buộc) đây là pha lâu nhất của chu kỳ sống (của sản phẩm). Phần mềm được cài đặt và được dùng trong thực tế. Bảo trì bao gồm điều chỉnh các lỗi mà chưa được phát hiện trong các giai đọan trước của chu kì sống; nâng cấp sự thực hiện của hệ thống các đơn vị và nâng cao hệ thống dịch vụ cho là các phát hiện về yêu cầu mới. Mô hình này, yêu cầu tiếp cận một cách truyền thống, tuần tự và chặt chẽ đối với việc phát triển phần mềm. Điểm yếu của mô hình này là nó không linh hoạt. Các bộ phận của đề án chia ra thành những phần riêng của các giai đoạn. Với mô hình này quá trình lặp lại là không tránh khỏi, nếu không quay lại thì dễ gặp bất trắc mà lặp lại thì khó quản lý tiến độ dẫn đến không đáp ứng kịp thời yêu cầu của khách hàng. Không phù hợp với hoàn cảnh phần mềm luôn thay đổi, thực hiện triển khai và phát triển đồng thời. Thời gian thực hiện dài và khách hàng phải đợi đến giai đoạn cuối mới có chương trình làm việc được. Nếu đến giai đoạn cuối mới phát hiện lỗi thì có thể là một thảm họa. Mặc dù vậy mô hình này phản ảnh thực tế công nghệ. Như là một hệ quả và đây vẫn là mô hình cơ sở cho đa số các hệ thống phát triển phần mềm, phần cứng. Mô hình chữ V Mô hình chữ V gần giống với mô hình thác nước, pha sau thực hiện khi pha trước đã thực hiện xong. Thực hiện test kết hợp với các pha trước nó. Ưu điểm: có thể thực hiện một số việc song song, đạt được phần mềm chất lượng, các pha tương thích và hỗ trợ nhau, các hoạt động kiểm thử được chú trọng. Nhược điểm: các yêu cầu phần mềm phải được đặc tả rõ ràng, pha trước thực hiện xong pha sau mới bắt đầu và người sử dụng không có cơ hội tham gia vào quá trình phát triển. Mô hình làm bản mẫu Tạo ra một mô hình như thực tế cho phần mềm cần xây dựng. Thực hiện thiết kế nhanh các bản mẫu rồi làm mịn dần và thực hiện trình diễn để người dùng đánh giá rồi tiếp tục làm mịn các yêu cầu. Là cách tiếp cận thực tế nhất, thích hợp với các hệ thống vừa và nhỏ. Nó được sử dụng hiệu quả khi kết hợp với các mô hình khác. 11 Mô hình xoắn ốc (Boehm-1988) Hình1.2: mô hình xoắn ốc Mô hình xoắn ốc dựa trên ý tưởng tối thiểu hóa rủi ro, bằng việc phân tích yếu tố rủi ro ở mỗi bước lặp và sử dụng phương pháp làm bản mẫu, hoàn thiện và phát triển hệ thống, duyệt lại và tiếp tục. Với phương pháp này thì các phiên bản được hoàn thiện dần và luôn có sự tham gia đánh giá của khách hàng. Mô hình này thích hợp để phát triển các hệ thống phần mềm với quy mô lớn. Trong mô hình này không có sự phân biệt rõ ràng giữa hoạt động bảo trì và phát triển. Mỗi vòng lặp đại diện cho một pha của quy trình phát triển phần mềm. Vòng trong cùng tập trung về tính khả thi, vòng kế tiếp lo về định nghĩa các yêu cầu, kế đến là thiết kế v.v. Trong mô hình này không có một pha nào được xem là cố định. Tuy nhiên, việc thay đổi một cách linh hoạt đòi hỏi nhà phát triển và khách hàng phải có sự liên hệ một cách chặt chẽ. 1.1.3. Mô hình phân tầng (layer) Trong phát triển ứng dụng, để dễ quản lý các thành phần của hệ thống, cũng như không bị ảnh hưởng bởi các thay đổi, người ta hay nhóm các thành phần có cùng chức năng lại với nhau và phân chia trách nhiệm cho từng nhóm để công việc không bị chồng chéo và ảnh hưởng lẫn nhau. Bạn sẽ nghe nói đến thuật ngữ kiến trúc đa tầng/nhiều tầng, mỗi tầng sẽ thực hiện một chức năng nào đó, trong đó mô hình ba tầng là phổ biến nhất. Mô hình ba tầng này là gì? Là tầng trình diễn (Presentation), tầng logic (Business Logic), và tầng CSDL (Data Access). Các tầng này sẽ giao tiếp với nhau thông qua các dịch vụ (services) mà mỗi tầng cung cấp để tạo nên ứng 12 dụng, tầng này cũng không cần biết bên trong tầng kia làm gì mà chỉ cần biết tầng kia cung cấp dịch vụ gì cho mình và sử dụng nó mà thôi. Tầng trình diễn (Presentation Layer) Tầng này làm nhiệm vụ giao tiếp với người dùng cuối để thu thập dữ liệu và hiển thị kết quả/dữ liệu thông qua các thành phần trong giao diện người sử dụng. Tầng này sẽ sử dụng các dịch vụ do tầng Business Logic cung cấp. Trong .NET thì bạn có thể dùng Windows Forms, ASP.NET hay Mobile Forms để hiện thực tầng này. Trong tầng này có 2 thành phần chính là User Interface Components và User Interface - UI Components là những phần tử chịu trách nhiệm thu thập và hiển thị thông tin cho người dùng cuối. Trong ASP.NET thì những thành phần này có thể là các TextBox, các Button, DataGrid… - UI Process Components: là thành phần chịu trách nhiệm quản lý các qui trình chuyển đổi giữa các UI Components. Ví dụ chịu trách nhiệm quản lý các màn hình nhập dữ liệu trong một loạt các thao tác định trước như các bước trong một Wizard… Business Logic Layer Tầng này thực hiện các nghiệp vụ chính của hệ thống, sử dụng các dịch vụ do tầng Data Access cung cấp, và cung cấp các dịch vụ cho tầng Presentation. Tầng này cũng có thể sử dụng các dịch vụ của các nhà cung cấp thứ 3 (3rd parties) để thực hiện công việc của mình (ví dụ như sử dụng dịch vụ của các cổng thanh toán trực tuyến như VeriSign, Paypal…). Data Access Layer Tầng này thực hiện các nghiệp vụ liên quan đến lưu trữ và truy xuất dữ liệu của ứng dụng. Thường tầng này sẽ sử dụng các dịch vụ của các hệ quản trị cơ sở dữ liệu như SQL Server, Oracle, … để thực hiện nhiệm vụ của mình. Trong tầng này có các thành phần chính là Data Access Logic, Data Sources, Servive Agents). 1.1.4. Lập trình hướng đối tượng Lập trình hướng đối tượng (Object-oriented programming - OOP), là kỹ thuật lập trình hỗ trợ công nghệ đối tượng. OOP được xem là giúp tăng năng suất, đơn giản 13 hóa độ phức tạp khi bảo trì cũng như mở rộng phần mềm bằng cách cho phép lập trình viên tập trung vào các đối tượng phần mềm ở bậc cao hơn. Ngoài ra, nhiều người còn cho rằng OOP dễ tiếp thu hơn cho những người mới học về lập trình hơn là các phương pháp trước đó. Lập trình hướng đối tượng dựa trên ba đặc trưng cơ bản là bao gói/che dấu thông tin, kế thừa và đa hình. Bao gói/che dấu thông tin là đặc trưng cơ bản nhất của OOP. Gồm hai công việc liên quan mật thiết với nhau: gắn kết dữ liệu và phương pháp xử lý dữ liệu này thành một thể thống nhất gọi là (lơp) đối tượng, che dấu các cài đặt và cấu trúc dữ liệu cụ thể của đối tượng, và các đối tượng chỉ đưa ra kết quả thông qua việc cấp các dịch vụ trên giao diện xác định. Thực hiện tốt việc bao gói/che dấu thông tin sẽ cho phép chúng ta thao tác với các đối tượng mà không cần biết cách thức cài đặt cụ thể của nó. Do việc sử dụng đối tượng chỉ cần biết thông tin tối thiểu về giao diện nên chúng ta dễ dàng sử dụng lại, đồng thời việc bảo trì là dễ dàng. Thêm nữa, do chỉ thay đổi được trạng thái của đối tượng thông qua các giao diện xác định nên có thể đảm bảo được các trạng thái của đối tượng là luôn đúng đắn. Kế thừa là cơ chế đặc biệt của lập trình hướng đối tượng, cho phép xây dựng một lớp đối tượng mới kế thừa lớp đối tượng đã có. Kế thừa thúc đẩy việc sử dụng lại trong bản thân một phần mềm cũng như giữa các phần mềm với nhau. Đa hình là cơ chế cho phép nhìn nhận một đối tượng theo các góc nhìn khác nhau, đồng thời cho phép các đối tượng khác nhau giải thích cùng một thông điệp theo các cách thức khác nhau. Cùng với kế thừa, đa hình tạo nên sự mềm dẻo đặc biệt trong lập trình hướng đối tượng. Đa hình đồng thời là nền tảng cho việc thực hiện các thiết kế mở và xây dựng các mẫu thiết kế [2]. 1.2. Chất lượng phần mềm 1.2.1. Khái niệm Trả lời câu hỏi thế nào là một phần mềm chất lượng là rất khó, ngay đối với phần mềm đang hoạt động, những người khác nhau có thể đánh giá về nó rất khác nhau. Theo định nghĩa hình thức về chất lượng phần mềm của Tổ chức tiêu chuẩn quốc tế ISO trong bộ tiêu chuẩn 8402, “chất lượng là khả năng đáp ứng toàn diện nhu cầu của người dùng về tính năng cũng như công dụng được nêu ra một cách tường minh hoặc không tường minh trong ngữ cảnh xác định”. Ngay trong định nghĩa này thì chất lượng cũng được định nghĩa một cách rất mờ, thiếu yếu tố định lượng. Thêm vào đó, để hiểu hết nhu cầu của người sử dụng quả thực là rất khó. Với những khó khăn về định lượng trong khái niệm chất lượng phần mềm, để có được 14 một phần mềm tốt, cách thông thường nhất là tiếp cận theo lối chất lượng quy trình. Nghĩa là nếu ta có quy trình sản xuất tốt thì sẽ có khả năng sản xuất ra sản phẩm tốt[2],[7] 1.2.2. Đảm bảo chất lượng phần mềm (SQA_ Software Quality Assuarance) Khi phần mềm trở thành sản phẩm và đòi hỏi đảm bảo chất lượng đáp ứng nhu cầu của người sử dụng thì hoạt động đảm bảo chất lượng phần mềm là một hoạt động cốt yếu được các doanh nghiệp sản xuất phần mềm quan tâm hàng đầu. Bởi vì hoạt động đảm bảo chất lượng phần mềm có những lợi ích: phần mềm có ít các khiếm khuyết hơn nên giảm phí tổn bảo trì, độ tin cậy cao hơn do đó thoả mãn nhu cầu khách hàng hơn, năng suất và hiệu quả hơn. Đảm bảo chất lượng phần mềm liên quan đến việc xem xét tất cả các sản phẩm phần mềm và các hoạt động trong vòng đời phát triển của chúng. Hoạt động đảm bảo chất lượng phần mềm luôn được tiến hành song song với quá trình phát triển của nó. Có như vậy nó mới vận hành và đáp ứng được nhu cầu của người sử dụng và không bị lỗi cùng với thời gian. Kiểm toán có thể được thực hiện để đảm bảo các sản phẩm và quy trình phù hợp với các chính sách tổ chức nội bộ và thủ tục phát triển phần mềm, cũng như tiêu chuẩn công nghiệp. Bộ tiêu chuẩn chất lượng ISO 9001 của tổ chức ISO, quy định về “Quy trình đảm bảo chất lượng” trong các tổ chức phát triển phần mềm. Chỉ số ISO 9001, xác nhận các tổ chức, đơn vị có quy trình đảm bảo chất lượng hợp chuẩn. Bên cạnh đó, mô hình khác là CMM (Capability Maturity Model) và CMMI (Capability Maturity Model Integration) cũng đang rất được quan tâm tại Việt Nam. Công ty nhận được chứng chỉ CMM nghĩa là công ty đó đã đạt được mức độ tương ứng với các cấp độ CMM của chứng chỉ. Tuy nhiên, chúng ta cần lưu ý đây mới là khả năng chứ chưa phải là chắc chắn. Ngày nay, cách tiếp cận của ISO, chất lượng toàn diện của phần mềm cần được quan tâm từ chất lượng quy trình, tới chất lượng phần mềm nội bộ (chất lượng trong), chất lượng phần mềm đối chiếu với yêu cầu của người dùng (chất lượng ngoài) và chất lượng phần mềm trong sử dụng (chất lượng sử dụng). Ngoài ra, người ta thường nói đến đảm bảo chất lượng tổng thể của phần mềm. Tức là những giải pháp để đảm bảo đạt được những độ đo khác nhau của phần mềm trong quá trình phát triển. Người ta hy vọng rằng, trong quá trình phát triển khi các độ đo đã được đảm bảo thì phần mềm chắc chắn sẽ đạt chất lượng. Chẳng hạn khi nói đến độ tin cậy của hệ thống, người ta thường quan tâm đến độ đo về tính sẵn sàng. Tuy nhiên, khi đánh giá về phần mềm, người ta thường đưa ra một số tiêu chí để nói đến chất lượng tổng thể của nó, đó là các chuẩn về công nghệ phần mềm. Tiếp theo sẽ giới thiệu về tiêu chí chất lượng phần mềm. Tiêu chí đánh giá chất lượng của phần mềm bao gồm: 15 - Đạt được các mục tiêu thiết kế đề ra của tổ chức (thực hiện được các chức năng của tổ chức). - Chi phí vận hành là chấp nhận được: chi phí không quá cao so với lợi nhuận mà nó mang lại. - Đáp ứng được các chuẩn mực của một hệ thống thông tin hiện hành. Chẳng hạn tính sẵn sàng: thời gian làm việc trong ngày, tuần, thời gian thực hiện một dịch vụ, một tìm kiếm, kết quả đưa ra đúng chuẩn (mẫu bảng biểu, số chỉ tiêu,…). - Sản phẩm tạo ra có giá trị xác đáng: Thông tin đưa ra là đúng đắn, kịp thời, có ý nghĩa thiết thực với hoạt động chức năng và quản lý, góp phần nâng cao chất lượng sản phẩm và dịch vụ của tổ chức. - Bảo trì được: Dễ bảo trì, bảo trì không quá tốn kém. - Khả dụng: Dễ đọc và dễ sử dụng. - Mềm dẻo – có khả năng làm thích nghi được: có thể kiểm tra, mở rộng ứng dụng và phát triển tiếp được. - Có tính khả chuyển: Có thể chuyển đổi từ môi trường làm việc này sang môi trường làm việc khác. Bốn mục tiêu phải đạt được để đáp ứng quá trình đảm bảo chất lượng phần mềm - Mục tiêu thứ 1: Hoạt động đảm bảo chất lượng phần mềm có kế hoạch - Mục tiêu thứ 2: Tuân thủ sản xuất phần mềm, thực hiện theo chuẩn, thủ tục và yêu cầu được xác minh khách quan - Mục tiêu thứ 3: Các cá nhân hoặc nhóm có ảnh hưởng phải được thông báo các hoạt động SQA và kết quả. - Mục tiêu thứ 4: Quản lý địa chỉ các vấn đề không tuân thủ dẫn đến không được giải quyết. Đảm bảo chất lượng phần mềm bắt đầu ngay từ giai đoạn yêu cầu của vòng đời phát triển sản phẩm. Kế hoạch đảm bảo chất lượng phần mềm (SQAP) nên được hoàn thành khi giai đoạn yêu cầu có đầy đủ các đặc điểm kỹ thuật mà phần mềm yêu cầu được cung cấp. Mỗi tổ chức có kế hoạch riêng cho từng dự án. Kế hoạch này phải được xem xét và có các số liệu cụ thể về chất lượng, phải được nhấn mạnh. 16 Việc thực hiện SQAP bắt đầu vào cuối của giai đoạn yêu cầu và kết thúc khi sản phẩm không còn sử dụng nữa. SQAP thực hiện trong suốt vòng đời phát triển của phần mềm không chỉ giai đoạn phát triển. Các khả năng được áp dụng để đảm bảo chất lượng phần mềm: - Đánh giá quá trình cụ thể của các mục tiêu đảm bảo chất lượng và các quá trình trong vòng đời phát triển của sản phẩm. Điều này đưa ra phương pháp tiếp cận của tổ chức để cải thiện quá trình tiếp theo. - Theo dõi sản phẩm chất lượng sau khi SQAP hoàn thành, nó được sử dụng cho chu kỳ phát triển sản phẩm cụ thể để giám sát các hoạt động chất lượng. - Tài liệu kế hoạch - xây dựng SQAP là kế hoạch phát triển quan trọng trong đảm bảo chất lượng phần mềm. - Giám sát phát triển, thực hiện SQAP cung cấp cho việc theo dõi quá trình phát triển sản phẩm. - Theo dõi tiến trình trong suốt dự án, SQAP hướng dẫn theo dõi các quá trình chất lượng phần mềm trong các dự án và quá trình phát triển. Mục tiêu của phần này là giúp người đọc có thể: - Xây dựng một kế hoạch đảm bảo chất lượng phần mềm phù hợp với mục tiêu của chuẩn CMM, hoặc ISO… - Xác định lợi ích của việc đảm bảo chất lượng phần mềm trong các dự án cụ thể - Xây dựng một SQAP hoàn chỉnh cho bất kỳ dự án phát triển phần mềm nào - Sửa đổi danh sách kiểm tra SQAP cho các dự án cụ thể của tổ chức - Kết hợp chặt chẽ đảm bảo chất lượng với các tổ chức tổng thể và chương trình, số liệu dự án Xây dựng kế hoạch đảm bảo chất lượng phần mềm bao gồm các bước chính sau: 1. Mục đích Khung SQAP là một phần đảm bảo chất lượng phần mềm đóng trong quản lý dự án tổng thể. - Xác định người sử dụng cuối 17 - Xác định mức độ rủi ro cần thiết cho giải pháp phát triển phần mềm - Sơ đồ khối phù hợp với hệ thống phần mềm khác - Dự kiến đối tượng cho SQAP - Biện minh của dự án - Chuyển giao phần mềm cụ thể được đảm bảo - Mô tả mô hình vòng đời phát triển của phần mềm được sử dụng - Danh sách các phần mềm COTS được sử dụng 2. Tài liệu tham khảo Danh sách đầy đủ các tài liệu như: tiêu chuẩn công nghiệp, sách giáo khoa… sử dụng để phát triển SQAP cần phải được sản xuất ở đây. Cùng với các tài liệu tham khảo bên ngoài, tất cả các chính sách tổ chức và các văn bản thủ tục áp dụng cần được liệt kê. Tài liệu dự án tham chiếu cần phải được cung cấp, bao gồm: - Danh sách tài liệu được hình thành trên cơ sở SQAP - Lý do đưa ra danh sách tài liệu được sử dụng - Danh sách các sai lệch với chuẩn - Danh sách chuyển giao phần mềm bao phủ bởi SQAP đó có yêu cầu bổ sung thực hành hoặc các thủ tục nghiêm ngặt hơn, hoặc thỏa mái hơn. - Ghi lại độ lệch phản ánh mức độ rủi ro trình bày trong phần cuối cùng và các tài liệu tham khảo để biện minh cho những sai lệch. 3. Quản lý Tổ chức: mô tả cấu trúc tổ chức ảnh hưởng và kiểm soát của phần mềm. Một sơ đồ tổ chức đơn giản cho thấy mối quan hệ của tổ chức phát triển với tổ chức đại diện lớn hơn. Đó là một tổ chức phát triển hơn 7 người bao gồm các mục: - Sơ đồ tổ chức tất cả các bên có liên quan và mối quan hệ của họ với tổ chức phát triển - Báo cáo và các đường dẫn trong tổ chức - Quy trình giải quyết xung đột - Theo dõi vấn đề cơ chế 18 - Thay đổi trách nhiệm ban kiểm soát và tổ chức Nhiệm vụ: - Các nhiệm vụ cụ thể được thực hiện trong quá trình SQA, bao gồm kiểm toán (kiểm tra), báo cáo và xem xét. - Các hành động cụ thể được thực hiện trên các phân phối cụ thể - Điểm cụ thể trong vòng đời phát triển phần mềm là SQA đóng vai trò tích cực trong đó. - Một sơ đồ quy trình làm việc của các hoạt động SQA trong dự án cụ thể Trách nhiệm: một bảng vai trò và trách nhiệm của tất cả các thành viên của nhóm phát triển phải được hiển thị. 4. Tài liệu Bao gồm các tài liệu hướng dẫn được theo dõi bởi SQAP. Các tài liệu được liệt kê ở đây có thể là tập hợp con của tất cả các mục cấu hình theo dõi trong kế hoạch quản lý cấu hình phần mềm. Các tài liệu khác sẽ được dự án phát triển cụ thể đưa ra: có thể là tài liệu vì các lý do của hợp đồng…. Danh sách các tài liệu tối thiểu trên một dự án phần mềm: - Kế hoạch quản lý dự án - Yêu cầu đặc điểm kỹ thuật phần mềm - Thiết kế đặc điểm kỹ thuật phần mềm - Kế hoạch thử nghiệm phần mềm - Kế hoạch quản lý rủi ro phần mềm - Kế hoạch quản lý cấu hình phần mềm - Tài liệu hướng dẫn người sử dụng 5. Tiêu chuẩn, thực hiện, quy ước và số liệu. 19 Đảm bảo chất lượng phần mềm được điều khiển bởi các tiêu chuẩn công nghiệp. Phần này liệt kê tất cả các yếu tố bên ngoài và yếu tố bên trong có ảnh hưởng đến chất lượng cuối cùng của sản phẩm phần mềm. Mục đích: Đầu tiên là tài liệu tham khảo, liệt kê tất cả các tài liệu tham chiếu có chứa các chuẩn, các chính sách và các thủ tục của dự án. Nhớ rằng, chức năng SQA là giám sát, theo dõi và chức năng quản lý kiểm tra, nó không phải là chức năng thực hiện. Mục đích của nó bao gồm: - Tham khảo thông qua việc tham khảo tất cả các tài liệu - Tham khảo thông qua việc giám sát, theo dõi và quản lý chức năng phù hợp với mỗi tài liệu - Tham khảo thông qua mỗi vị trí xảy ra trong vòng đời phát triển Nội dung: Lý do cơ bản cho tất cả các phần “Các chuẩn, thực tiễn, quy ước và số liệu” để cung cấp các đường cơ sở cho việc đo sản phẩm dự án. Mặc dù việc tham khảo đưa ra một bức tranh lớn lý do đằng sau và quá trình theo dõi, giám sát, đảm bảo quản lý. 6. Tổng quan, kiểm toán Xem xét và kiểm tra là các hoạt động SQA, cung cấp cơ chế kiểm thử để xác định tiến độ dự án và vòng lặp phản hồi cho các nhà phát triển để kiểm tra chất lượng sản phẩn trong tiến trình. Mục tiêu: Bước này sẽ hiển thị các thông tin. - Xác định kỹ thuật, người quản lý giám sát và kiểm tra thực hiện - Quy tắc, thủ tục đánh giá và kiểm tra được thực hiện - Tối thiểu người tham dự kiểm tra, đánh giá để tiến hành - Tham chiếu tài liệu tất cả các đánh giá và kiểm tra vòng đời dự án. - Tối thiểu bản ghi chuẩn cho tất cả các giám sát - Sắp xếp tiến trình cho các vấn đề phát hiện trong suốt quá trình đánh giá và kiểm tra - Sử dụng hệ thống theo dõi vấn đề 20 - Sử dụng kiểm soát thay đổi Đây là những đánh giá cần thiết để hoàn thành các hoạt động SQA của dự án: - Xem trước kế hoạch quản lý dự án - Xem xét và chỉ rõ yêu cầu phần mềm - Xem xét thiết kế phần mềm - Xem xét lập kế hoạch kiểm thử phần mềm - Xem xét kế hoạch quản lý rủi ro phần mềm - Xem xét kế hoạch quản lý cấu hình phần mềm - Người sử dụng xem tài liệu hướng dẫn - Chức năng kiểm tra là một phần quan trọng - Kiểm tra vật lý đối với mã và tài liệu hướng dẫn nội bộ - Kiểm tra quá trình thiết kế để nhất quán viết mã - Quản lý đánh giá tiến trình truy cập và tuân thủ thủ tục - Xem xét các bài học kinh nghiệm từ cuối mỗi dự án 7. Quản lý rủi ro Một số dự án yêu cầu một SQAP cũng có một kế hoạch quản lý rủi ro. Các tài liệu tham khảo SQAP như là một trong những rủi ro cụ thể được giảm nhẹ thông qua việc sử dụng SQAP. Các mục bao gồm: - Tham chiếu chéo để có kế hoạch giảm rủi ro cụ thể hỗ trợ bởi SQAP - Phát biểu cách giảm các lớp rủi ro cụ thể cho dự án Xem xét chu kỳ SQA, đặc biệt nhấn mạnh việc giảm nhẹ rủi ro Tham khảo những rủi ro định kỳ, với việc xem xét, đánh giá và kiểm tra SQAP cụ thể Yêu cầu báo cáo SQAP rủi ro ở trên và kế hoạch quản lý rủi ro - 8. Báo cáo và hành động sửa chữa