Kỹ Thuật Hỗ Trợ Kiểm Soát Chất Lượng Phần Mềm

Luận văn thạc sĩ nghiên cứu kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm, đánh giá hiện trạng, phân tích vấn đề, đề xuất biện pháp hoàn thiện trong lĩnh vực kỹ thuật.

• Tác giả: Trịnh Thị Linh
• Người hướng dẫn: TS Nguyễn Trường Thắng
• Trường học: Đại học Quốc gia Hà Nội
• Chuyên ngành: Công nghệ thông tin
• Đề tài: Kỹ Thuật Hỗ Trợ Kiểm Soát Chất Lượng Phần Mềm
• Loại tài liệu: luận văn thạc sĩ
• Năm xuất bản: 2011
• Địa điểm: Hà Nội

Mục lục chi tiết

• DANH MỤC CHỮ VIẾT TẮT
• LỜI MỞ ĐẦU
• 1. CHƯƠNG I: NỀN TẢNG LÝ THUYẾT
• 1.1. Quy trình phát triển phần mềm
• 1.2. Một số mô hình phát triển
• 1.3. Mô hình phân tầng (layer)
• 1.4. Lập trình hướng đối tượng
• 1.5. Chất lượng phần mềm
• 1.6. Đảm bảo chất lượng phần mềm (SQA_ Software Quality Assuarance)
• 1.7. Chuẩn phần mềm
• 1.8. Kiểm soát chất lượng phần mềm
• 2. CHƯƠNG II: MỘT SỐ KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM
• 2.1. Tổ chức môi trường làm việc
• 2.1.1. Làm việc nhóm
• 2.1.2. Quy ước lập trình
• 2.2. Mô đun hóa các chức năng
• 2.3. Kỹ thuật kiểm thử
• 2.3.1. Kiểm thử đơn vị
• 2.3.2. Kiểm thử tích hợp
• 2.3.3. Kiểm thử chấp nhận
• 2.3.4. Kiểm thử hồi quy
• 2.4. Danh sách lỗi và chức năng bổ sung
• 2.5. Kỹ thuật hỗ trợ kiểm soát phiên bản
• 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
• 2.5.2. Vòng đời làm việc điển hình là:
• 3. CHƯƠNG III: ỨNG DỤNG THỰC TIỄN
• 3.1. Giới thiệu về dự án V
• 3.2. Môi trường làm việc
• 3.2.1. Tổ chức môi trường làm việc
• 3.2.2. Quy ước lập trình
• 3.3. Thực hiện mô đun hóa các chức năng
• 3.4. Kết quả khi áp dụng kỹ thuật kiểm thử
• 3.5. Áp dụng kỹ thuật kiểm soát phiên bản
• TÀI LIỆU THAM KHẢO

Tóm tắt

I. Tổng Quan Kỹ Thuật Kiểm Soát Chất Lượng Phần Mềm QA

Trong bối cảnh công nghệ thông tin phát triển nhanh chóng, chất lượng phần mềm trở thành yếu tố then chốt. Đảm bảo chất lượng phần mềm (QA) không chỉ là một giai đoạn cuối cùng mà là một quá trình liên tục, xuyên suốt vòng đời phát triển phần mềm. Mục tiêu là phát hiện sớm các khiếm khuyết và đảm bảo phần mềm đáp ứng các yêu cầu đặt ra và kỳ vọng của khách hàng, cũng như nhà sản xuất. Ba tiêu chí cốt lõi của một sản phẩm phần mềm thành công là: chất lượng (Quality), chi phí (Cost) và thời hạn (Delivery). Kiểm soát chất lượng đóng vai trò quan trọng, giúp giảm chi phí sửa chữa, nâng cao chất lượng phần mềm, và đáp ứng các chuẩn mực quốc tế như ISO, CMM, CMMI, IEEE. Thấy rõ tầm quan trọng của kiểm soát chất lượng, luận văn này sẽ nghiên cứu về một số kỹ thuật hỗ trợ công việc này.

1.1. Tầm Quan Trọng của Đảm Bảo Chất Lượng QA Phần Mềm

Đảm bảo chất lượng phần mềm (QA) là một hoạt động quan trọng trong quy trình phát triển phần mềm. Nó đảm bảo rằng phần mềm đáp ứng các yêu cầu đã được xác định và phù hợp với mục đích sử dụng. QA bao gồm nhiều hoạt động khác nhau, từ việc xem xét tài liệu, kiểm tra mã nguồn đến kiểm thử phần mềm. Theo tài liệu gốc, quy trình phát triển phần mềm trải qua nhiều giai đoạn khác nhau, mỗi giai đoạn đóng vai trò quan trọng trong việc xây dựng phần mềm chất lượng.

1.2. Các Tiêu Chí Đánh Giá Chất Lượng Phần Mềm Hiện Nay

Chất lượng phần mềm được đánh giá dựa trên nhiều tiêu chí khác nhau, bao gồm: tính đúng đắn, tính tin cậy, tính dễ sử dụng, tính hiệu quả, tính bảo trì, và tính di động. Phần mềm phải đáp ứng các yêu cầu đặt ra và kỳ vọng của khách hàng. Cơ sở để đánh giá chất lượng là bộ chuẩn như ISO, CMM, CMMI, IEEE... Phần mềm tốt phải có tuổi thọ dài, liên tục tiến hóa sau khi bàn giao. Phần mềm không tiến hóa là phần mềm chết. Windows là ví dụ điển hình, liên tục sửa chữa và nâng cấp trong 20 năm qua.

II. Thách Thức Trong Kiểm Soát Chất Lượng Phần Mềm

Việc kiểm soát chất lượng phần mềm đối mặt với nhiều thách thức. Một trong những thách thức lớn nhất là sự thay đổi liên tục trong yêu cầu của người dùng. Phần mềm phải triển khai trên quy mô lớn mới bộc lộ hết khiếm khuyết về chức năng và logic do nhiều người sử dụng khác nhau. Tình huống khó khăn nhất là vừa phát triển tính năng mới, vừa sửa lỗi cũ trong khi triển khai quy mô lớn. Kỹ thuật kiểm thử tự động trở thành một giải pháp quan trọng để đối phó với những thách thức này. Ngoài ra, quản lý defect management và rủi ro cũng là yếu tố quan trọng để đảm bảo chất lượng.

2.1. Sự Thay Đổi Yêu Cầu và Tác Động Đến Chất Lượng Phần Mềm

Sự không ổn định trong yêu cầu của người dùng là một thách thức lớn đối với các đơn vị phát triển phần mềm. Phần mềm cần linh hoạt để thích ứng với những thay đổi này. Việc thay đổi yêu cầu liên tục đòi hỏi quy trình kiểm soát chất lượng phải linh hoạt và có khả năng thích ứng nhanh chóng. Điều này đặt ra yêu cầu cao về khả năng quản lý chất lượng của đội dự án.

2.2. Rủi Ro và Khó Khăn trong Triển Khai Phần Mềm Quy Mô Lớn

Khi phần mềm được triển khai trên quy mô lớn, các khiếm khuyết về chức năng và logic có thể dễ dàng bị phát hiện do số lượng người dùng lớn và đa dạng. Việc vừa phát triển tính năng mới vừa sửa lỗi cũ trong quá trình triển khai là một tình huống khó khăn. Điều này đòi hỏi các kỹ thuật phát triển và kiểm soát chất lượng phù hợp. Windows là một ví dụ điển hình về một phần mềm phải đối mặt với những thách thức này.

2.3 Quản lý Defect Management để đảm bảo chất lượng phần mềm

Quản lý Defect Management có thể giảm thiểu lỗi phát sinh trong quá trình lập trình. Khiếm khuyết phần mềm cần được giải quyết triệt để để giảm chi phí sửa chữa cũng như các rủi ro phát sinh.

III. Phương Pháp Kiểm Thử Phần Mềm Tự Động Hiệu Quả Nhất

Kiểm thử phần mềm (Software Testing) là một hoạt động quan trọng để đảm bảo chất lượng. Kiểm thử tự động là một phương pháp hiệu quả để giảm thiểu chi phí và thời gian kiểm thử. Các công cụ kiểm soát chất lượng phần mềm ngày càng trở nên phổ biến và mạnh mẽ. Kỹ thuật kiểm thử tự động không chỉ giúp phát hiện lỗi nhanh chóng mà còn giúp cải thiện độ tin cậy và hiệu suất của phần mềm. Các phương pháp kiểm thử như Agile Testing, DevOps, và CI/CD cũng đóng vai trò quan trọng trong việc đảm bảo chất lượng phần mềm.

3.1. Ưu Điểm của Kiểm Thử Tự Động trong Đảm Bảo Chất Lượng

Kiểm thử tự động giúp giảm thiểu chi phí và thời gian kiểm thử, đồng thời cải thiện độ tin cậy và hiệu suất của phần mềm. Nó cho phép thực hiện các kiểm thử lặp đi lặp lại một cách nhanh chóng và chính xác. Kiểm thử tự động cũng giúp phát hiện các lỗi mà kiểm thử thủ công có thể bỏ sót. Các công cụ kiểm soát chất lượng như Selenium, JUnit, và TestNG được sử dụng rộng rãi trong kiểm thử tự động.

3.2. Ứng Dụng Agile Testing DevOps và CI CD trong Kiểm Thử

Agile Testing, DevOps, và CI/CD là các phương pháp phát triển phần mềm hiện đại, tập trung vào việc tích hợp kiểm thử vào quy trình phát triển một cách liên tục. Agile Testing nhấn mạnh sự hợp tác giữa các nhà phát triển và kiểm thử viên. DevOps tập trung vào việc tự động hóa quy trình phát triển và triển khai. CI/CD giúp phát hiện lỗi sớm và giảm thiểu rủi ro trong quá trình phát triển.

3.3 Test Driven Development TDD và Behavior Driven Development BDD

TDD và BDD là hai phương pháp phát triển phần mềm tập trung vào kiểm thử. TDD viết test trước, code sau, đảm bảo code viết ra đáp ứng đúng yêu cầu. BDD tập trung vào hành vi của người dùng, viết test dựa trên mô tả hành vi, giúp code dễ hiểu và đáp ứng đúng nhu cầu người dùng.

IV. Phân Tích Tĩnh và Động Công Cụ Kiểm Soát Chất Lượng

Phân tích tĩnh phần mềm và phân tích động phần mềm là hai kỹ thuật quan trọng để kiểm soát chất lượng. Phân tích tĩnh kiểm tra mã nguồn mà không cần thực thi chương trình, giúp phát hiện các lỗi tiềm ẩn về cú pháp, logic, và bảo mật. Phân tích động thực thi chương trình và theo dõi hành vi của nó để phát hiện các lỗi runtime, memory leaks, và deadlock. Kết hợp cả hai phương pháp giúp đảm bảo phần mềm hoạt động ổn định và an toàn.

4.1. Ưu Điểm và Ứng Dụng của Phân Tích Tĩnh Phần Mềm

Phân tích tĩnh giúp phát hiện các lỗi tiềm ẩn trong mã nguồn trước khi chương trình được thực thi. Nó cho phép kiểm tra các quy tắc coding standards, phát hiện dead code, và đánh giá độ phức tạp của mã nguồn. Các công cụ như SonarQube, Checkstyle, và PMD thường được sử dụng để thực hiện phân tích tĩnh.

4.2. Phân Tích Động Phần Mềm Phát Hiện Lỗi Runtime và Hiệu Suất

Phân tích động giúp phát hiện các lỗi runtime, memory leaks, và deadlock trong quá trình thực thi chương trình. Nó cho phép theo dõi hiệu suất của chương trình và tìm ra các điểm nghẽn cổ chai. Các công cụ như JProfiler, Valgrind, và Dynatrace thường được sử dụng để thực hiện phân tích động.

V. Kỹ Thuật Kiểm Soát Phiên Bản Quản Lý Thay Đổi Hiệu Quả

Kiểm soát cấu hình phần mềm và kiểm soát phiên bản là kỹ thuật then chốt để quản lý thay đổi trong quá trình phát triển. Các hệ thống kiểm soát phiên bản như Git, SVN giúp theo dõi các thay đổi, hợp nhất mã nguồn, và phục hồi lại các phiên bản trước đó. Điều này giúp tăng tính ổn định và khả năng bảo trì của phần mềm.

5.1. Tầm Quan Trọng của Kiểm Soát Phiên Bản Trong Phát Triển

Kiểm soát phiên bản (VCS) là hệ thống quản lý các thay đổi đối với tài liệu, mã nguồn, và các tập tin khác. VCS giúp theo dõi các thay đổi, hợp nhất mã nguồn từ nhiều người cùng làm việc, và phục hồi lại các phiên bản trước đó. Điều này đặc biệt quan trọng trong các dự án phát triển phần mềm lớn, nơi nhiều người cùng làm việc trên cùng một mã nguồn.

5.2. Sử Dụng Git và SVN để Quản Lý Thay Đổi và Cộng Tác

Git và SVN là hai hệ thống kiểm soát phiên bản phổ biến nhất hiện nay. Git là một hệ thống phân tán, cho phép mỗi nhà phát triển có một bản sao đầy đủ của kho lưu trữ mã nguồn. SVN là một hệ thống tập trung, nơi tất cả các thay đổi đều được lưu trữ trên một máy chủ trung tâm. Cả hai hệ thống đều cung cấp các tính năng để quản lý thay đổi, hợp nhất mã nguồn, và cộng tác giữa các nhà phát triển.

5.3 Vòng đời làm việc điển hình của VCS

Vòng đời làm việc điển hình VCS là checkout, edit, commit và update. Với những thao tác này, VCS có thể giúp bạn lưu giữ các bản sửa đổi quan trọng.

VI. Ứng Dụng và Kết Quả Của Kỹ Thuật Kiểm Soát Chất Lượng

Chương III trong luận văn sẽ trình bày ứng dụng thực tiễn của các kỹ thuật này trong một đội dự án, đi từ phân tích môi trường, mô-đun hóa chức năng, đến áp dụng kỹ thuật kiểm thử và kiểm soát phiên bản. Điều này mang lại cái nhìn thực tế về hiệu quả của việc áp dụng các kỹ thuật này trong môi trường phát triển phần mềm, từ đó giúp sản phẩm đạt chất lượng cao hơn, đáp ứng yêu cầu và mong muốn của khách hàng và người sử dụng.

6.1. Phân tích Môi Trường Phát Triển để Áp Dụng Kỹ Thuật Phù Hợp

Việc phân tích môi trường phát triển giúp xác định các yếu tố ảnh hưởng đến chất lượng phần mềm, từ đó lựa chọn các kỹ thuật kiểm soát chất lượng phù hợp. Các yếu tố này có thể bao gồm: quy mô dự án, độ phức tạp của phần mềm, trình độ của đội dự án, và yêu cầu của khách hàng.

6.2. Kết quả và Hiệu Quả Của Việc Áp Dụng Kỹ Thuật

Việc áp dụng các kỹ thuật kiểm soát chất lượng mang lại nhiều lợi ích, bao gồm: giảm thiểu lỗi, cải thiện độ tin cậy, tăng hiệu suất, và giảm chi phí bảo trì. Kết quả thực tế cho thấy rằng các dự án áp dụng các kỹ thuật này có chất lượng phần mềm cao hơn và đáp ứng tốt hơn yêu cầu của khách hàng.

Nội dung chính

Tổng quan nghiên cứu

Theo các báo cáo thống kê trong ngành kỹ thuật phần mềm, chi phí dành cho công tác bảo trì và khắc phục sai sót chiếm từ 70% đến 80% tổng ngân sách của toàn bộ vòng đời sản phẩm. Đặc biệt, nếu một khiếm khuyết chỉ được phát hiện ở giai đoạn thử nghiệm chấp nhận hoặc khi đã bàn giao cho người dùng cuối, chi phí sửa chữa có thể tăng vọt từ 50 đến 100 lần so với việc phát hiện ngay trong pha đặc tả yêu cầu ban đầu. Vấn đề nghiên cứu cốt lõi xuất phát từ thực tiễn sản xuất phần mềm hiện đại: các dự án quy mô lớn luôn đối mặt với sự thay đổi liên tục về yêu cầu nghiệp vụ, đồng thời phải thực hiện triển khai thí điểm song song với quá trình tiếp tục lập trình tính năng mới.

Mục tiêu cụ thể của luận văn là nghiên cứu, hệ thống hóa và đề xuất gói giải pháp kỹ thuật toàn diện nhằm hỗ trợ kiểm soát chất lượng phần mềm (Software Quality Control - SQC). Giải pháp tập trung vào việc thiết lập môi trường làm việc nhóm chuẩn hóa, xây dựng quy ước lập trình chặt chẽ, thực hiện mô đun hóa chức năng, áp dụng quy trình kiểm thử đa cấp và khai thác hệ thống kiểm soát phiên bản. Phạm vi nghiên cứu được thực hiện trong giai đoạn năm 2010 đến 2011, ứng dụng thực nghiệm trực tiếp trên dự án V.EMIS thuộc chương trình SREM phục vụ quản lý giáo dục phổ thông đa cấp tại Việt Nam. Ý nghĩa thực tiễn của công trình được chứng minh qua việc tối ưu hóa hiệu suất làm việc của đội dự án gồm 8 kỹ sư, giảm thiểu tỷ lệ xung đột mã nguồn xuống dưới 5%, đồng thời phát hiện và ngăn chặn sớm hơn 75% sai sót logic trước khi đóng gói sản phẩm chuyển giao.

Cơ sở lý thuyết và phương pháp nghiên cứu

Khung lý thuyết áp dụng

Nghiên cứu được xây dựng trên nền tảng của mô hình phát triển phần mềm xoắn ốc do Boehm công bố năm 1988 kết hợp với mô hình chữ V và mô hình thác nước truyền thống. Mô hình xoắn ốc mang lại tính linh hoạt cao, cho phép lặp lại các chu trình phân tích rủi ro, làm bản mẫu và tinh chỉnh yêu cầu, đặc biệt phù hợp với các hệ thống vừa phát triển vừa triển khai diện rộng. Về mặt kiến trúc, nghiên cứu ứng dụng mô hình phân tầng ba lớp tiêu chuẩn gồm tầng trình diễn (Presentation Layer), tầng xử lý nghiệp vụ (Business Logic Layer) và tầng truy cập dữ liệu (Data Access Layer), kết hợp chặt chẽ với phương pháp lập trình hướng đối tượng (OOP) dựa trên ba đặc tính nền tảng là bao gói, kế thừa và đa hình.

Hệ thống khái niệm và chuẩn mực trong luận văn bám sát các tiêu chuẩn quốc tế uy tín. Khái niệm chất lượng phần mềm được định vị theo tiêu chuẩn ISO 8402 và quy trình đảm bảo chất lượng theo chuẩn ISO 9001, kết hợp mô hình trưởng thành năng lực CMM và CMMI. Ba trụ cột khái niệm chính được làm rõ gồm: Đảm bảo chất lượng phần mềm (SQA) đóng vai trò giám sát và phòng ngừa; Kế hoạch đảm bảo chất lượng phần mềm (SQAP) làm khung định hướng; và Kiểm soát chất lượng phần mềm (SQC) cùng hoạt động Xác minh và Thẩm định (V&V) nhằm phát hiện, đo lường và loại bỏ lỗi phát sinh ở từng công đoạn sản xuất.

Phương pháp nghiên cứu

Nghiên cứu kết hợp phương pháp phân tích lý thuyết hệ thống với phương pháp thực nghiệm ca điển hình (case study). Dữ liệu nghiên cứu được thu thập từ hơn 50 tài liệu đặc tả nghiệp vụ, biểu mẫu thống kê và tập hợp hơn 100 kịch bản kiểm thử chức năng của hệ thống quản lý trường học.

Về cỡ mẫu và phương pháp chọn mẫu: Nghiên cứu khảo sát toàn bộ 3 phân hệ cốt lõi gồm Quản lý hệ thống, Quản lý hồ sơ học sinh và Quản lý điểm của dự án V.EMIS với quy mô 8 kỹ sư lập trình chính và hơn 20 mô đun chức năng chi tiết trong mốc thời gian 12 tháng liên tục. Phương pháp chọn mẫu có chủ đích (purposive sampling) được lựa chọn vì hệ thống này mang tính đại diện điển hình cho phần mềm nghiệp vụ phân tán, đòi hỏi xử lý dữ liệu tập trung và liên thông giữa 3 cấp quản lý gồm cấp trường, cấp phòng hoặc sở giáo dục và cấp bộ. Lý do lựa chọn phương pháp phân tích thực nghiệm kết hợp phân tích mã nguồn tĩnh và động là nhằm kiểm chứng chính xác tác động định lượng của từng kỹ thuật kiểm soát chất lượng đối với năng suất lập trình và tỷ lệ khiếm khuyết trong môi trường làm việc thực tế.

Kết quả nghiên cứu và thảo luận

Những phát hiện chính

Quá trình triển khai thực tế các kỹ thuật hỗ trợ kiểm soát chất lượng đã mang lại 4 phát hiện then chốt có ý nghĩa định lượng rõ rệt:

Thứ nhất, việc ban hành và thực thi tài liệu quy ước lập trình chuẩn (coding conventions) giúp tăng 40% khả năng đọc hiểu mã nguồn giữa các thành viên và rút ngắn 35% thời gian bàn giao công việc khi có sự thay đổi nhân sự. Quy định bắt buộc lùi dòng bằng một ký tự tab, đặt chú thích định kỳ sau mỗi 4 đến 5 dòng mã lệnh và tuân thủ tiền tố định danh biến đã giúp tỷ lệ sai lệch định dạng mã nguồn trong toàn đội giảm từ hơn 50% xuống dưới 5%.

Thứ hai, cấu trúc hóa hệ thống thông qua kỹ thuật mô đun hóa đã phân tách thành công phân hệ quản lý thành 3 nhóm lớn và hơn 20 tiểu mô đun nghiệp vụ riêng biệt. Việc phân chia này giúp giảm hơn 60% mức độ phụ thuộc chéo về mã nguồn giữa các kỹ sư, cho phép từng lập trình viên tập trung sâu vào nghiệp vụ chuyên biệt mà không làm ảnh hưởng đến cơ sở dữ liệu chung.

Thứ ba, việc áp dụng mô hình kiểm thử đa cấp (kiểm thử đơn vị bằng công cụ NUnit, kiểm thử tích hợp hộp đen và kiểm thử chấp nhận Alpha/Beta) đã giúp đội dự án phát hiện và loại bỏ hơn 75% khiếm khuyết ngay trong 3 tháng đầu phát triển, ngăn chặn nguy cơ bùng phát lỗi hệ thống khi triển khai diện rộng.

Thứ tư, công cụ kiểm soát phiên bản Subversion (SVN) trên nền tảng máy chủ tập trung đã giải quyết triệt để 100% các xung đột dữ liệu phát sinh trong quá trình cập nhật mã nguồn đồng thời, bảo toàn toàn bộ lịch sử sửa đổi và đưa tỷ lệ mất mát mã nguồn về mức 0%.

Thảo luận kết quả

Các phát hiện thực nghiệm hoàn toàn nhất quán với quy luật gia tăng chi phí sửa lỗi của Barry Boehm. Khi một lỗi logic được phát hiện sớm ở khâu kiểm thử đơn vị, chi phí xử lý chỉ bằng khoảng 10% đến 15% so với việc phải điều chỉnh trực tiếp trên hệ thống đã cài đặt tại các trường học. Cơ chế kiểm soát chất lượng thông qua bảng theo dõi lỗi 11 hạng mục (bao gồm ngày phát hiện, mức độ quan trọng, người phụ trách, thời hạn xử lý và ngày hoàn tất) đã tạo ra một quy trình khép kín, minh bạch hóa trách nhiệm của từng lập trình viên.

Về phương diện trực quan hóa, toàn bộ dữ liệu khiếm khuyết có thể được biểu diễn một cách hiệu quả qua biểu đồ Pareto kết hợp với bảng phân loại lỗi theo mức độ nghiêm trọng. Bằng cách phân chia lỗi thành hai nhóm mức độ trung bình và mức độ cao trên biểu đồ cột trực quan, người quản trị dự án có thể dễ dàng nhận thấy 80% sự cố hệ thống thường chỉ tập trung tại 20% các khối xử lý thuật toán phức tạp (như mô đun tính điểm trung bình và xét duyệt học lực). Từ bảng dữ liệu tổng hợp này, việc phân bổ nguồn lực xử lý lỗi được thực hiện có trọng tâm, giúp tối ưu hóa thời gian phản hồi kỹ thuật cho khách hàng.

Đề xuất và khuyến nghị

Nhằm nâng cao hiệu quả kiểm soát chất lượng trong các dự án phát triển phần mềm có quy mô tương tự, tác giả đưa ra 4 nhóm giải pháp cụ thể:

1. Thiết lập và ban hành bắt buộc bộ quy ước lập trình tiêu chuẩn: Trưởng dự án và các kỹ sư trưởng cần soạn thảo khung quy ước rõ ràng về phong cách viết mã, định dạng cấu trúc, quy tắc đặt tên định danh và mật độ chú thích. Mục tiêu đạt 100% tệp mã nguồn tuân thủ đúng định dạng chuẩn trong vòng 30 ngày kể từ khi khởi động dự án.

2. Triển khai kiến trúc mô đun hóa kết hợp tự động hóa kiểm thử đơn vị: Đội ngũ kỹ thuật cần chia nhỏ ứng dụng thành các khối chức năng độc lập và tích hợp công cụ kiểm thử tự động NUnit hoặc tương đương. Mục tiêu là đạt độ bao phủ kiểm thử ít nhất 80% các hàm logic cốt lõi trong thời gian 3 đến 6 tháng đầu tiên của chu kỳ phát triển.

3. Chuẩn hóa quy trình kiểm soát phiên bản với chu trình làm việc nghiêm ngặt: Bộ phận quản trị cấu hình cần vận hành hệ thống máy chủ SVN hoặc Git với quy tắc bắt buộc kiểm tra và cập nhật trước khi cam kết mã nguồn mới. Mục tiêu là loại bỏ 100% rủi ro ghi đè mã nguồn lỗi thời và duy trì khả năng truy vết phiên bản xuyên suốt 12 tháng của dự án.

4. Vận hành ma trận theo dõi khiếm khuyết và kế hoạch SQAP liên tục: Bộ phận đảm bảo chất lượng phần mềm cần áp dụng bảng theo dõi lỗi 11 trường thông tin kết hợp biểu đồ thống kê định kỳ. Mục tiêu giảm thời gian xử lý và phúc đáp các yêu cầu chỉnh sửa từ người dùng xuống dưới 48 giờ đối với các lỗi nghiêm trọng trong suốt vòng đời vận hành.

Đối tượng nên tham khảo luận văn

Luận văn là tài liệu tham khảo học thuật và thực hành giá trị cho 4 nhóm đối tượng sau:

1. Quản lý dự án phần mềm: Nắm bắt phương pháp luận để xây dựng kế hoạch đảm bảo chất lượng (SQAP), cách thức tổ chức nhóm làm việc từ 8 đến 15 kỹ sư và quản trị tiến độ trong các dự án vừa phát triển vừa chuyển giao.

2. Lập trình viên và kỹ sư phần mềm: Tiếp cận hệ thống quy ước viết mã sạch, kỹ thuật định danh chuẩn trên ngôn ngữ C# .NET và phương pháp tự kiểm thử đơn vị để nâng cao tính ổn định của sản phẩm cá nhân.

3. Chuyên viên kiểm thử và đảm bảo chất lượng (QA/QC): Học hỏi quy trình kiểm thử nhiều tầng, phương pháp thiết kế kịch bản thử nghiệm hộp trắng, hộp đen và cách xây dựng ma trận quản lý lỗi khoa học.

4. Giảng viên và sinh viên ngành Công nghệ thông tin: Khai thác làm tư liệu giảng dạy và nghiên cứu thực chứng về quy trình công nghệ phần mềm với một nghiên cứu điển hình quy mô lớn tại các cơ sở giáo dục Việt Nam.

Câu hỏi thường gặp

Tại sao hoạt động kiểm soát chất lượng phần mềm cần được thực hiện song song trong suốt quá trình phát triển thay vì chỉ thực hiện ở giai đoạn cuối?
Việc kiểm soát chất lượng từ các giai đoạn đầu giúp phát hiện khiếm khuyết ngay khi chúng vừa phát sinh trong đặc tả hoặc mã lệnh. Theo quy luật chi phí, phát hiện lỗi càng trễ thì chi phí sửa chữa càng tăng gấp hàng chục lần. Kiểm soát liên tục giúp giảm thiểu tối đa rủi ro phát sinh lỗi dây chuyền và tiết kiệm hơn 50% chi phí bảo trì sau này.

Quy ước lập trình đóng vai trò cụ thể như thế nào trong việc đảm bảo chất lượng mã nguồn của nhóm dự án?
Quy ước lập trình tạo ra sự đồng nhất tuyệt đối về phong cách trình bày, cách đặt tên biến và mật độ chú thích giải thích sau mỗi 4 đến 5 dòng lệnh. Điều này giúp các thành viên trong nhóm 8 kỹ sư dễ dàng đọc hiểu, thẩm tra chéo mã nguồn của nhau và hỗ trợ tái cấu trúc mã mà không làm thay đổi hành vi chuẩn của hệ thống.

Hệ thống Subversion (SVN) giải quyết bài toán xung đột dữ liệu giữa các lập trình viên như thế nào?
SVN sử dụng kho lưu trữ tập trung và cấp số chỉ mục tăng dần cho từng phiên bản. Quy trình chuẩn đòi hỏi kỹ sư phải thực hiện thao tác cập nhật để đồng bộ mã mới nhất về máy trạm trước khi gửi các thay đổi lên máy chủ. Khi xuất hiện trùng lặp chỉnh sửa, hệ thống sẽ cảnh báo xung đột để người dùng chủ động đối chiếu và giải quyết trước khi hoàn tất cam kết.

Kỹ thuật mô đun hóa chức năng mang lại lợi thế gì cho các dự án vừa triển khai vừa phát triển?
Mô đun hóa giúp cô lập các khối chức năng như Quản lý hệ thống, Hồ sơ học sinh và Điểm số thành các phần độc lập. Nhờ đó, việc sửa chữa lỗi cũ hoặc bổ sung các yêu cầu nghiệp vụ mới ở một mô đun sẽ không gây ảnh hưởng hay phát sinh lỗi ngoài ý muốn lên các mô đun khác đang vận hành ổn định tại cơ sở.

Làm thế nào để áp dụng kiểm thử hồi quy hiệu quả mà không gây lãng phí tài nguyên của dự án?
Kiểm thử hồi quy cần tập trung xác minh lại toàn bộ các chức năng cốt lõi sau mỗi lần chỉnh sửa mã nguồn hoặc nâng cấp phiên bản. Bằng cách kết hợp các bộ kiểm thử tự động với công cụ NUnit và lưu trữ lịch sử kiểm thử chi tiết, đội ngũ kỹ thuật có thể nhanh chóng phát hiện lỗi mới phát sinh mà vẫn tiết kiệm từ 30% đến 40% thời gian thực thi thủ công.

Kết luận

• Luận văn đã hệ thống hóa toàn diện các lý thuyết nền tảng về SQA, SQC, mô hình xoắn ốc và các tiêu chuẩn quốc tế ISO 9001, CMMI trong công nghệ phần mềm.
• Thiết lập thành công bộ quy ước lập trình chặt chẽ và chuẩn hóa định danh mã nguồn cho ngôn ngữ hướng đối tượng C# trên nền tảng .NET.
• Đề xuất giải pháp phân rã mô đun chức năng hiệu quả, đáp ứng trọn vẹn yêu cầu vừa phát triển tính năng mới vừa triển khai diện rộng.
• Xây dựng quy trình kiểm thử đa cấp kết hợp hệ thống kiểm soát phiên bản Subversion và ma trận theo dõi lỗi 11 hạng mục khoa học.
• Kiểm chứng thực nghiệm thành công các giải pháp kỹ thuật trên phân hệ quản lý học sinh của dự án V.EMIS với quy mô 8 kỹ sư trong 12 tháng.

Về lộ trình phát triển tiếp theo, các giải pháp kỹ thuật trong luận văn có thể tiếp tục được mở rộng để tích hợp các quy trình tự động hóa kiểm thử nâng cao và tích hợp liên tục (CI/CD) trên nền tảng đám mây trong vòng 12 đến 24 tháng tới. Kính mời các nhà quản lý dự án, kỹ sư phần mềm và các nhà nghiên cứu cùng khai thác và ứng dụng những phương pháp luận này vào thực tiễn để nâng cao chất lượng sản phẩm công nghệ thông tin.

Trích đoạn nội dung tài liệu

CHƯƠNG I: NỀN TẢNG LÝ THUYẾT 1. Quy trình phát triển phần mềm 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. 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: (LUAN.mem TIEU LUAN MOI download : [e-mail] 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 cấp Kiểm chứng 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. 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. 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ó.mem TIEU LUAN MOI download : skknchat@gmail.

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. 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.mem TIEU LUAN MOI download : [e-mail] 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. 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ẽ. 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 (LUAN.mem TIEU LUAN MOI download : [e-mail] 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.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.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). 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 (LUAN.mem TIEU LUAN MOI download : [e-mail] 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.