NỀN TẢNG LÝ THUYẾT
Quy trình phát triển phần mềm
Quy trình phát triển phần mềm bao gồm các giai đoạn và kết quả liên quan để tạo ra sản phẩm phần mềm Đây là yếu tố quan trọng giúp các nhà sản xuất phần mềm đạt được thành công, cho phép tất cả thành viên trong dự án, từ cũ đến mới, xử lý công việc một cách đồng bộ theo cách thức chung của công ty hoặc ở cấp độ dự án Hầu hết các hoạt động này được thực hiện 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
Trong lĩnh vực phát triển phần mềm, có nhiều mô hình khác nhau như 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 và mô hình CMM/CMMI Mỗi mô hình đều mang những đặc điểm, ưu điểm và nhược điểm riêng, phù hợp với từng loại dự án cụ thể Do đó, việc lựa chọn mô hình phát triển phù hợp là rất quan trọng và cần được xem xét kỹ lưỡng bởi người quản lý dự án, dựa trên đặc điểm và yêu cầu của dự án.
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ó
Xác định yêu cầu hệ thống
Yêu cầu cấp phát Thiết kế căn bản
Xác định yêu cầu phần mềm
Hình 1.1: Mô hình thác nước
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 phát triển phần mềm truyền thống yêu cầu quy trình tuần tự và chặt chẽ, nhưng điểm yếu lớn nhất của nó là tính không linh hoạt Các giai đoạn của dự án được chia thành những phần riêng biệt, dẫn đến việc khó quản lý tiến độ và đáp ứng kịp thời yêu cầu của khách hàng Quá trình lặp lại là điều không thể tránh khỏi, và nếu không quay lại, dễ gặp rủi ro; ngược lại, nếu lặp lại, sẽ khó kiểm soát Mô hình này không phù hợp với sự thay đổi liên tục của phần mềm, khi mà việc triển khai và phát triển cần diễn ra đồng thời Thời gian thực hiện kéo dài khiến khách hàng phải chờ đến giai đoạn cuối mới có sản phẩm, và phát hiện lỗi vào giai đoạn cuối có thể dẫn đến thảm họa Tuy nhiên, mô hình này vẫn phản ánh thực tế công nghệ và là cơ sở cho nhiều hệ thống phát triển phần mềm và phần cứng hiện nay.
Mô hình chữ V tương tự như mô hình thác nước, với các giai đoạn thực hiện tuần tự, trong đó giai đoạn sau chỉ bắt đầu khi giai đoạn trước đã hoàn thành Quá trình kiểm thử được thực hiện song song với các giai đoạn phát triển trước đó Ưu điểm của mô hình này là cho phép thực hiện một số công việc đồng thời, đảm bảo chất lượng phần mềm cao, các giai đoạn hỗ trợ và tương thích lẫn nhau, đồng thời chú trọng vào các hoạt động kiểm thử.
Nhược điểm của phương pháp phát triển phần mềm này là yêu cầu phần mềm cần được định nghĩa một cách rõ ràng Các giai đoạn phát triển phải được thực hiện tuần tự, với giai đoạn sau chỉ bắt đầu khi giai đoạn trước đã hoàn thành Hơn nữa, người sử dụng không có cơ hội tham gia vào quá trình phát triển, điều này có thể dẫn đến việc sản phẩm cuối cùng không đáp ứng đúng nhu cầu của họ.
Mô hình làm bản mẫu
Tạo ra mô hình thực tế cho phần mềm là bước quan trọng trong quá trình phát triển Bắt đầu bằng việc thiết kế nhanh các bản mẫu, sau đó tinh chỉnh và trình diễn để người dùng đánh giá, từ đó tiếp tục hoàn thiện các yêu cầu Phương pháp này phù hợp nhất cho các hệ thống vừa và nhỏ, và đạt hiệu quả cao khi kết hợp với các mô hình khác.
Mô hình xoắn ốc (Boehm-1988)
Hình1.2: mô hình xoắn ốc
Mô hình xoắn ốc tập trung vào việc tối thiểu hóa rủi ro thông qua phân tích yếu tố rủi ro ở từng bước lặp, kết hợp với phương pháp làm bản mẫu để hoàn thiện và phát triển hệ thống Quá trình này luôn có sự tham gia đánh giá của khách hàng, giúp các phiên bản được cải tiến dần dần Mô hình này rất phù hợp cho việc phát triển các hệ thống phần mềm quy mô lớn, không phân biệt rõ giữa bảo trì và phát triển Mỗi vòng lặp trong mô hình đại diện cho một pha trong quy trình phát triển phần mềm, bắt đầu từ tính khả thi, tiếp theo là định nghĩa yêu cầu, rồi đến thiết kế, và các bước tiếp theo.
Trong mô hình này, không có giai đoạn nào được xác định là cố định Tuy nhiên, việc thay đổi linh hoạt yêu cầu sự liên kết chặt chẽ giữa nhà phát triển và khách hàng.
1.1.3 Mô hình phân tầng (layer)
Trong phát triển ứng dụng, việc nhóm các thành phần có chức năng tương tự và phân chia trách nhiệm giúp quản lý hệ thống hiệu quả hơn, tránh tình trạng chồng chéo và ảnh hưởng lẫn nhau Kiến trúc đa tầng, đặc biệt là mô hình ba tầng, rất phổ biến Mô hình này bao gồm tầng trình diễn (Presentation), tầng logic (Business Logic), và tầng CSDL (Data Access) Các tầng này giao tiếp qua các dịch vụ mà mỗi tầng cung cấp, cho phép chúng hoạt động độc lập mà không cần biết chi tiết về hoạt động bên trong của nhau.
Tầng trình diễn (Presentation Layer)
Tầng giao diện người dùng chịu trách nhiệm giao tiếp với người dùng cuối, thu thập dữ liệu và hiển thị kết quả thông qua các thành phần trong giao diện Tầng này sử dụng các dịch vụ từ tầng Business Logic Trong NET, bạn có thể sử dụng Windows Forms, ASP.NET hoặc Mobile Forms để triển khai tầng này.
Trong tầng này có 2 thành phần chính là User Interface Components và User
Chất lượng phần mềm
Việc xác định thế nào là một phần mềm chất lượng là một thách thức, vì đánh giá này có thể khác nhau giữa các cá nhân Theo tiêu chuẩn ISO 8402, "chất lượng là khả năng đáp ứng nhu cầu của người dùng về tính năng và công dụng, dù được nêu rõ hay không." Định nghĩa này vẫn còn mơ hồ và thiếu yếu tố định lượng Hơn nữa, việc hiểu rõ nhu cầu của người sử dụng là rất khó khăn Do đó, để phát triển phần mềm tốt, phương pháp phổ biến là tập trung vào quy trình chất lượng, tức là có quy trình sản xuất tốt sẽ dẫn đến sản phẩm tốt.
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, hoạt động đảm bảo chất lượng phần mềm trở nên cốt yếu cho các doanh nghiệp sản xuất phần mềm Đảm bảo chất lượng giúp giảm thiểu khiếm khuyết, giảm chi phí bảo trì, nâng cao độ tin cậy và đáp ứng tốt hơn nhu cầu khách hàng Quá trình này liên quan đến việc xem xét tất cả các sản phẩm phần mềm và hoạt động trong vòng đời phát triển của chúng, diễn ra song song với quá trình phát triển Kiểm toán cũng được thực hiện để đảm bảo sản phẩm và quy trình phù hợp với chính sách nội bộ, thủ tục phát triển phần mềm và tiêu chuẩn công nghiệp.
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 phát triển phần mềm, xác nhận các tổ chức có quy trình đảm bảo chất lượng hợp chuẩn Ngoài ISO 9001, các mô hình khác như CMM (Capability Maturity Model) và CMMI (Capability Maturity Model Integration) cũng được áp dụng để nâng cao khả năng quản lý chất lượng trong các tổ chức.
Mô hình tích hợp đang thu hút sự chú ý tại Việt Nam, với chứng chỉ CMM chứng minh rằng công ty đã đạt các cấp độ tương ứng Tuy nhiên, cần lưu ý rằng đây chỉ là khả năng và không phải là sự đảm bảo Hiện nay, cách tiếp cận của ISO nhấn mạnh tầm quan trọng của chất lượng toàn diện phần mềm, bao gồm chất lượng quy trình, chất lượng phần mềm nội bộ (chất lượng trong), chất lượng phần mềm theo yêu cầu người dùng (chất lượng ngoài) và chất lượng phần mềm trong quá trình sử dụng (chất lượng sử dụng).
Đảm bảo chất lượng tổng thể của phần mềm là một yếu tố quan trọng trong quá trình phát triển Các giải pháp nhằm đạt được các độ đo khác nhau của phần mềm sẽ giúp nâng cao chất lượng sản phẩm cuối cùng Khi các độ đo được đảm bảo, phần mềm sẽ có khả năng đạt được độ tin cậy cao, đặc biệt là về tính sẵn sàng của hệ thống.
Khi đánh giá phần mềm, các tiêu chí về công nghệ phần mềm thường được sử dụng để xác định chất lượng tổng thể Bài viết này sẽ giới thiệu các tiêu chí quan trọng liên quan đến 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:
- Đạ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
Hệ thống thông tin hiện hành cần đáp ứng các chuẩn mực quan trọng, bao gồm tính sẵn sàng trong suốt thời gian làm việc trong ngày và tuần Điều này liên quan đến thời gian thực hiện dịch vụ và tìm kiếm, cũng như đảm bảo kết quả đạt tiêu chuẩn, như mẫu bảng biểu và các chỉ tiêu số liệu.
Sản phẩm được tạo ra mang lại giá trị thiết thực, với thông tin chính xác và kịp thời, có ý nghĩa quan trọng cho hoạt động chức năng và quản lý Điều này 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 là quản lý địa chỉ các vấn đề không tuân thủ để đảm bảo chất lượng phần mềm từ giai đoạn yêu cầu trong 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) cần hoàn thành khi giai đoạn yêu cầu có đầy đủ đặc điểm kỹ thuật Mỗi tổ chức nên có kế hoạch riêng cho từng dự án, và kế hoạch này phải được xem xét kỹ lưỡng với các số liệu cụ thể về chất lượng được nhấn mạnh.
Việc thực hiện SQAP bắt đầu từ giai đoạn yêu cầu và kéo dài cho đến khi sản phẩm không còn sử dụng SQAP được áp dụng xuyên suốt vòng đời phát triển phần mềm, không chỉ giới hạn trong 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á chi tiết các mục tiêu đảm bảo chất lượng và quy trình trong vòng đời phát triển sản phẩm giúp tổ chức xác định phương pháp cải tiến cho các quy trình tiếp theo.
Sau khi hoàn thành SQAP, việc theo dõi chất lượng sản phẩm là rất quan trọng Điều này giúp giám sát các hoạt động chất lượng trong suốt chu kỳ phát triển sản phẩm cụ thể.
- 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:
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
- 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
Danh sách tài liệu phát triển SQAP bao gồm tiêu chuẩn công nghiệp, sách giáo khoa và các tài liệu tham khảo bên ngoài Tất cả chính sách tổ chức và văn bản thủ tục áp dụng cần được liệt kê đầy đủ Ngoài ra, tài liệu dự án tham chiếu cũng cần được cung cấp để đảm bảo tính chính xác và hiệu quả trong quá trình phát triển.
- 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
Cấu trúc tổ chức ảnh hưởng và kiểm soát phần mềm là yếu tố quan trọng trong việc phát triển hiệu quả Một sơ đồ tổ chức đơn giản có thể minh họa mối quan hệ giữa tổ chức phát triển và tổ chức đại diện lớn hơn Tổ chức phát triển này bao gồm hơn 7 thành viên, với các mục tiêu và chức năng rõ ràng.
- 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ế
- Thay đổi trách nhiệm ban kiểm soát và tổ chức
- 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ị
Bao gồm các tài liệu hướng dẫn được theo dõi bởi SQAP, danh sách nà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 Ngoài ra, các tài liệu khác sẽ được dự án phát triển cụ thể cung cấp, có thể bao gồm tài liệu liên quan đến các lý do 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
MỘT SỐ KỸ THUẬT HỖ TRỢ KIỂM SOÁT CHẤT LƯỢNG PHẦN MỀM
Đánh giá
Đánh giá là bước đầu tiên và quan trọng trong kiểm soát chất lượng phần mềm, giúp phát hiện lỗi và khiếm khuyết sớm hơn so với thử nghiệm So với kiểm thử, đánh giá tiêu tốn ít tài nguyên hơn và có thể thực hiện bởi một nhóm nhỏ, dễ dàng ghi lại và thay đổi lịch trình Quá trình này diễn ra liên tục trong suốt vòng đời phát triển phần mềm, đặc biệt quan trọng trong các dự án lớn với yêu cầu thay đổi liên tục Kiểm soát chất lượng nhằm phát hiện và loại bỏ khiếm khuyết, với đánh giá đóng vai trò chủ chốt trong nhiệm vụ này Đánh giá xác minh rằng sản phẩm ở mỗi giai đoạn phát triển đều chính xác với đầu vào và hoạt động, thường được gọi là kiểm thử trước mã Sự khác biệt giữa đánh giá và kiểm thử nằm ở phương pháp thực hiện.
Có nhiều hình thức đánh giá, bao gồm đánh giá ngang hàng như one on one, walk throughs, inspections, và audits Ngoài ra, còn có các hình thức đánh giá như xác minh, điểm quyết định, kiểm toán vật lý và chức năng, hoặc đánh giá sau thực hiện Mục tiêu chính của tất cả các hình thức đánh giá này là xác định những khiếm khuyết trong các sản phẩm đang được xem xét.
Boehm và cộng sự đã phát triển một đồ thị cho thấy chi phí khắc phục các khuyết tật trong sản phẩm gia tăng nhanh chóng theo thời gian Việc đánh giá nhằm phát hiện các khuyết tật ngay từ giai đoạn đầu, thay vì chỉ dựa vào kiểm thử và hoạt động để nhận diện chúng sau này.
Hình 2.1: Costs of identified defects
Mỗi đánh giá đều có mục đích, đối tượng và người tham gia cụ thể Một số đánh giá, như thiết kế walk-throughs, có thể diễn ra nhiều lần trong quá trình phát triển, trong khi các đánh giá khác, như kiểm toán chức năng, đóng vai trò quan trọng tại các thời điểm nhất định để hỗ trợ quyết định về sản phẩm Dù ở trường hợp nào, định dạng và quy trình đánh giá cần phải tuân thủ các tiêu chuẩn của tổ chức.
Chất lượng phần mềm đóng vai trò quan trọng trong việc đánh giá và cần được lên kế hoạch cẩn thận trong suốt vòng đời phát triển Nhiều tổ chức giao nhiệm vụ cho bộ phận chất lượng phần mềm chủ trì các đánh giá, và điều này cần được cập nhật thường xuyên Mặc dù tất cả các đánh giá đều phải tuân thủ quy trình, một số hình thức như one-on-ones hoặc walk-throughs có thể được miễn trừ Các thành viên trong nhóm cần tích cực tham gia, ghi chép biên bản và hành động khi cần thiết, đồng thời đảm bảo rằng các vấn đề được giải quyết trước khi chấp nhận và ghi nhận đánh giá Cuối cùng, người quản trị cần nắm rõ tình hình đánh giá và kết quả để đảm bảo tính hiệu quả của quy trình.
Tổ chức môi trường làm việc
Trong xã hội công nghệ thông tin hiện đại, phần mềm đóng vai trò thiết yếu với quy mô sản xuất ngày càng lớn và đa dạng Mỗi phần mềm không chỉ phục vụ một máy tính cá nhân mà còn có thể sử dụng trên nhiều thiết bị và cho nhiều cơ sở khác nhau Để đáp ứng yêu cầu về thời gian và chất lượng, các nhà sản xuất phần mềm cần tối ưu hóa quy trình phát triển, giảm chi phí và đảm bảo sản phẩm được giao đúng hạn Điều này tạo dựng niềm tin cho khách hàng và tăng khả năng cạnh tranh giữa các nhà phát triển Do đó, việc phát triển phần mềm quy mô lớn thường đòi hỏi sự hợp tác của nhiều người trong nhóm, nhằm đáp ứng tốt nhất nhu cầu của thị trường.
Phần mềm phát triển giúp rút ngắn thời gian nhưng cũng tạo ra thách thức cho người quản lý dự án Để vượt qua những khó khăn này, người quản lý cần có khả năng giải quyết vấn đề hiệu quả và đưa ra giải pháp giúp các thành viên trong nhóm làm việc đồng bộ Việc trao đổi thông tin, dữ liệu, mã nguồn và tài liệu giữa các thành viên là rất quan trọng, thường được thực hiện qua mô hình client-server trong mạng LAN hoặc Internet Người quản lý cũng cần chọn ngôn ngữ phát triển và công cụ hỗ trợ phù hợp, đồng thời quản lý dữ liệu trên máy chủ, nơi lưu trữ tài liệu, cơ sở dữ liệu và lịch sử công việc Dựa vào thông tin từ máy chủ, người quản lý có thể theo dõi tiến độ và điều chỉnh kế hoạch khi cần thiết Hơn nữa, việc tạo ra bầu không khí làm việc thoải mái sẽ giúp các thành viên trong nhóm làm việc tích cực và hiệu quả hơn.
Việc sử dụng ngôn ngữ lập trình hướng đối tượng trong phát triển phần mềm quy mô lớn là hợp lý, giúp các nhóm phát triển mã hóa chương trình một cách dễ dàng và hiệu quả Điều này không chỉ nâng cao kiểm soát quy trình làm việc mà còn cải thiện chất lượng sản phẩm, tạo uy tín cho khách hàng và thương hiệu cho đội phát triển Để quản lý chương trình và công việc của các thành viên hiệu quả, người quản lý dự án đã tổ chức các cuộc họp với nhóm để thống nhất quy ước lập trình, đảm bảo sự đồng thuận trong phương pháp thực hiện.
Mục đích xây dựng tài liệu quy ước lập trình là tạo sự thống nhất trong phong cách lập trình giữa các thành viên trong nhóm, giúp việc trao đổi, kế thừa, đọc hiểu và bảo trì kết quả công việc trở nên dễ dàng hơn Làm việc theo nhóm đòi hỏi sự khác biệt so với phong cách làm việc cá nhân, vì vậy việc thiết lập quy ước là rất cần thiết.
Theo Wikipedia, quy ước lập trình (coding conventions) là tập hợp hướng dẫn cho từng ngôn ngữ lập trình, định hướng phong cách, kỹ năng và phương pháp cho mọi khía cạnh của chương trình Chúng bao gồm tổ chức file, lùi dòng, chú thích, khai báo, lệnh, khoảng trắng, cách đặt tên, và các quy tắc lập trình Việc tuân thủ các quy ước này giúp nâng cao tính dễ hiểu của mã nguồn và tăng cường khả năng bảo trì phần mềm Các quy ước này được tài liệu hóa để toàn bộ đội phát triển hoặc công ty phần mềm tuân thủ, nhưng không được kiểm soát bởi các chương trình dịch, do đó, việc không tuân thủ không ảnh hưởng đến khả năng chạy chương trình.
Giảm chi phí bảo trì phần mềm là lý do chính để tuân thủ quy ước lập trình Trong phần giới thiệu về quy ước lập trình cho ngôn ngữ Java, Sun Microsystems đã đưa ra những phản biện quan trọng liên quan đến vấn đề này.
- 80% chi phí toàn cuộc đời của một phần mềm là ở khâu bảo trì
- Hầu như không có một phần mềm nào được bảo trì trong toàn vòng đời của nó bởi người tác giả đầu tiên
- Quy ước lập trình tăng tính đọc hiểu của phần mềm, cho phép các kỹ sư/lập trình viên hiểu mã nguồn nhanh và thấu đáo hơn hẳn
- Nếu bạn coi mã nguồn như một sản phẩm, bạn cần đảm bảo rằng nó được đóng gói kỹ lưỡng và sạch sẽ như mọi sản phẩm khác
Thẩm tra phần mềm (software peer review) thường liên quan tới đọc mã nguồn
Việc viết mã nguồn theo những chỉ dẫn nhất quán không chỉ giúp cho những người thẩm tra dễ dàng đọc và đánh giá, mà còn làm cho phần mềm trở nên dễ bảo trì hơn cho cả tác giả ban đầu.
Tái tinh chỉnh mã nguồn (Refactoring)
Refactoring là quá trình bảo trì mã nguồn nhằm cải thiện tính dễ hiểu và cấu trúc của nó Trong giai đoạn này, phần mềm thường được điều chỉnh để tuân thủ các tiêu chuẩn lập trình của đội phát triển trước khi phát hành Quan trọng là, mọi thay đổi trong refactoring không làm thay đổi hành vi của phần mềm Một số hoạt động refactoring phổ biến bao gồm đổi tên biến, đổi tên hàm, di chuyển hàm hoặc lớp, và chia nhỏ những hàm quá lớn thành các hàm nhỏ hơn.
Tự động hóa quá trình kiểm soát quy ước lập trình
Quy ước lập trình cho phép các chương trình đơn giản xử lý mã nguồn mà không cần biên dịch thành chương trình thực thi Một số công cụ đơn giản có thể được sử dụng để đếm số dòng mã nguồn hoặc thiết lập cơ sở cho các dự đoán tương lai của dự án Để hỗ trợ quá trình này, các thẻ đặc biệt có thể được thêm vào phần chú thích mã nguồn nhằm cải thiện tài liệu hóa, với các ví dụ tiêu biểu như JavaDoc và Doxygen, những công cụ này quy định việc sử dụng một tập hợp các thẻ nhất định.
Quy ước lập trình giúp đơn giản hóa quá trình phát triển phần mềm mới, tập trung vào việc xử lý các phần mềm đã có Kỹ thuật phân tích mã nguồn tĩnh, được phát triển từ những năm 1950, đóng vai trò quan trọng trong việc này.
Mô đun hóa các chức năng
Phát triển phần mềm quy mô lớn với nhiều chức năng đồng nghĩa với việc cần triển khai và phát triển đồng thời trong nhóm Điều này tạo ra thách thức cho các dự án phần mềm, đặc biệt là làm thế nào để tối ưu hóa tốc độ phát triển mà không gây chồng chéo trong quá trình làm việc, đồng thời vẫn đảm bảo chất lượng sản phẩm.
Giải pháp cho các đội phát triển là chia nhỏ dự án thành các mô đun chức năng, mỗi mô đun được giao cho một cá nhân hoặc nhóm thực hiện, trong khi vẫn sử dụng chung một cơ sở dữ liệu Giai đoạn này được giám sát chặt chẽ để đảm bảo chất lượng Việc phân chia này cũng giúp quản lý dễ dàng theo dõi tiến độ công việc Sau khi phân công, các thành viên sẽ tập trung nghiên cứu chuyên sâu về nghiệp vụ của mình, giúp tài liệu yêu cầu và thiết kế chi tiết hơn, đồng thời rút ngắn thời gian để chuyển sang giai đoạn lập trình Nghiên cứu kỹ lưỡng giúp kiểm soát quá trình mã hóa, đảm bảo các dòng lệnh và chức năng đáp ứng yêu cầu chất lượng Nhờ vậy, lập trình trở nên hiệu quả hơn, tăng năng suất dự án, giảm chi phí và nâng cao chất lượng phần mềm.
Việc lựa chọn môi trường làm việc và phân chia dự án thành các mô-đun chức năng đặt ra thách thức trong việc đồng bộ công việc của các thành viên trong đội dự án Để tránh những hiểu lầm có thể ảnh hưởng đến chất lượng sản phẩm, nhóm phát triển cần tuân thủ nghiêm ngặt các quy ước lập trình đã được thống nhất Điều này đòi hỏi mỗi thành viên trong nhóm phải có ý thức chấp hành các quy định đã thiết lập.
Kỹ thuật kiểm thử
Kiểm thử phần mềm là một hoạt động thiết yếu trong quy trình phát triển phần mềm, đóng vai trò quan trọng trong việc đánh giá chất lượng sản phẩm Đây là giai đoạn bắt buộc trong các dự án phát triển phần mềm không chỉ ở Việt Nam mà còn trên toàn thế giới Kỹ thuật kiểm thử giúp kiểm soát và nâng cao chất lượng của phần mềm, đảm bảo rằng sản phẩm đáp ứng yêu cầu và mong đợi của người dùng.
Theo Glen Myers, kiểm thử phần mềm là quá trình thực hiện chương trình nhằm phát hiện lỗi Một ca kiểm thử hiệu quả là ca có khả năng cao để tìm ra lỗi chưa được phát hiện, trong khi một ca kiểm thử thành công là ca làm lộ ra ít nhất một lỗi mới Do đó, mục tiêu của chúng ta là thiết kế các ca kiểm thử nhằm phát hiện một cách hệ thống các loại lỗi khác nhau với chi phí thời gian và công sức tối thiểu.
Để phát hiện lỗi trong phần mềm, quy trình kiểm thử thường bao gồm ba bước chính: tạo dữ liệu thử nghiệm, thực thi phần mềm với dữ liệu đó và quan sát kết quả thu được.
Các phép kiểm thử được thực hiện ở các mức độ khác nhau bởi những cá nhân khác nhau, mỗi mức đều mang ý nghĩa riêng trong quá trình phát triển sản phẩm Dưới đây là một số mức kiểm thử quan trọng.
Kiểm thử đơn vị là phương pháp kiểm tra phần mềm nhằm xác định tính phù hợp của các modul hay chương trình riêng lẻ Đơn vị nhỏ nhất có thể kiểm thử được bao gồm phương thức, thủ tục, hàm, lớp, v.v Đây là giai đoạn kiểm thử sớm nhất, kết hợp giữa kiểm thử cấu trúc và kiểm thử chức năng, giúp phát hiện các khiếm khuyết và sai sót trong mã nguồn, cũng như kiểm tra tính logic và các yêu cầu đã được xác định Thông thường, kiểm thử này được thực hiện bởi lập trình viên, người sẽ chạy từng đoạn mã để đảm bảo rằng nó hoạt động đúng theo cấu trúc và chức năng đã được thiết kế, đồng thời đáp ứng các tiêu chuẩn chất lượng Những sai sót được phát hiện sẽ được xem xét và khắc phục kịp thời, đồng thời tìm cách ngăn ngừa sự xuất hiện của các khiếm khuyết mới.
Để thực hiện kiểm thử hiệu quả, người kiểm thử cần can thiệp trực tiếp vào mã lệnh, do đó phương pháp kiểm thử hộp trắng là lựa chọn tối ưu cho việc kiểm thử nội bộ sản phẩm.
Kiểm soát các sai sót và khiếm khuyết trong giai đoạn kiểm thử đơn vị là cách hiệu quả để đảm bảo chất lượng phần mềm, từ đó đạt được các tiêu chuẩn chất lượng đã đề ra.
Kiểm thử tích hợp là quá trình kết hợp các thành phần thành mô đun chức năng, hệ con và hệ thống hoàn chỉnh, với mục tiêu kiểm tra chức năng như giao diện, hiệu ứng giữa các mô đun, tính đúng đắn và hiệu quả của phần mềm Việc thêm các đơn vị vào hệ thống thường được thực hiện theo hai chiến lược: top-down hoặc bottom-up, và thường do nhóm kiểm thử độc lập thực hiện Tại giai đoạn này, kiểm thử viên kiểm tra sự tương tác giữa các mô đun để đảm bảo tính phù hợp với thiết kế, sử dụng phương pháp hộp đen và có thể bổ sung phương pháp hộp trắng khi cần Thông qua kiểm thử tích hợp, chất lượng sản phẩm được kiểm soát, và kết quả kiểm thử cần được lập tài liệu để ghi lại lỗi và quy trình gây lỗi, từ đó giúp sửa chữa và rút kinh nghiệm cho các thành viên trong lập trình.
Kiểm thử chấp nhận là quá trình có sự tham gia của khách hàng hoặc đại diện của họ nhằm xác minh phần mềm có đáp ứng yêu cầu và không có lỗi hay khiếm khuyết Quá trình này sử dụng dữ liệu thực từ người dùng và thường bao gồm hai giai đoạn: kiểm thử alpha do nhà phát triển quản lý và kiểm thử beta không có sự quản lý của nhà phát triển, với lỗi được gửi lại để sửa chữa Qua kiểm thử chấp nhận, người dùng có thể đưa ra thêm yêu cầu, giúp phần mềm được mở rộng và nâng cấp, từ đó tăng cường khả năng đáp ứng nhu cầu của khách hàng và kéo dài thời gian sống của sản phẩm.
Kiểm thử hồi quy là quá trình kiểm tra lại phần mềm sau khi có sửa chữa hoặc thay đổi, nhằm đảm bảo rằng các chức năng của phần mềm mới hoạt động tốt như phiên bản cũ và không phát sinh lỗi mới Mặc dù kiểm thử hồi quy tốn nhiều thời gian và chi phí, nhưng nó là bước không thể thiếu, vì việc bỏ qua có thể dẫn đến các lỗi nghiêm trọng không lường trước được.
Trong phát triển dự án phần mềm, đảm bảo chất lượng, kiểm soát chất lượng và cải tiến chất lượng là yếu tố quyết định cho thành công Kiểm soát chất lượng trong suốt vòng đời phát triển giúp phát hiện khiếm khuyết sớm, giảm chi phí sửa đổi và bảo trì Điều này không chỉ nâng cao giá trị mà còn cải thiện chất lượng phần mềm khi đưa vào sử dụng.
2.4.5 Danh sách lỗi và chức năng bổ sung
Phần mềm quy mô lớn thường gặp khó khăn trong việc triển khai và phát triển đồng thời, vì điều này có thể dẫn đến việc bổ sung yêu cầu để đáp ứng nhu cầu khách hàng Để kiểm soát quá trình phát triển, cần lập danh sách các khiếm khuyết và lỗi phát hiện trong quá trình đánh giá, kiểm thử và yêu cầu bổ sung.
Ngày phát hiện vấn đề (ghi cụ thể hiện tượng)
Loại (câu hỏi/yêu cầu)
Thời hạn dự định xử lý
Ngày dự định kết thúc
Ngày dự định phúc đáp việc xử lý
Ngày thực sự hoàn tất
Bảng 2 1: các hạng mục khi liệt kê lỗi Ý nghĩa các mục trong bảng danh sách liệt kê
Ngày phát hiện vấn đề sẽ được ghi lại cụ thể khi thực hiện đánh giá và kiểm thử, trong đó các khiếm khuyết hoặc sai sót được ghi theo thứ tự các bước thực hiện Thông thường, phần này do nhà phát triển thực hiện, nhưng đôi khi người sử dụng cũng có thể phát hiện lỗi khi áp dụng dữ liệu thực tế mà nhà phát triển không lường trước Khi phần mềm được triển khai tới người sử dụng, có thể có yêu cầu bổ sung hoặc sửa đổi để phù hợp hơn với nhu cầu, bao gồm cải thiện giao diện để dễ sử dụng và thân thiện hơn, hoặc thêm các chức năng mới.
- Mô tả lỗi: chỉ rõ lỗi thể hiện như thế nào
- Loại (câu hỏi, yêu cầu) o Yêu cầu thêm vào o Lỗi không đáp ứng yêu cầu o Lỗi logic…
Tầm quan trọng của việc sửa chữa phần mềm được phân loại thành hai mức: mức trung bình và mức cao Ở mức trung bình, phần mềm vẫn có thể hoạt động bình thường mà không gặp phải ảnh hưởng lớn, do đó việc sửa chữa có thể không cần thiết ngay lập tức Ngược lại, ở mức cao, việc sửa chữa cần được thực hiện sớm để tránh ảnh hưởng đến các phần khác của hệ thống hoặc phát sinh lỗi mới.
- Ngày ghi nhận: ghi lại thời điểm phát hiện lỗi hoặc thời điểm tiếp nhận yêu cầu từ phía khách hàng
- Người phát hiện: ghi tên người phát hiện ra lỗi
Người phụ trách cần xác định lỗi thuộc về thành viên hoặc đơn vị nào trong phần nội dung gây ra sự cố Qua bảng miêu tả lỗi, các thành viên sẽ nhận thức được trách nhiệm của mình và tìm kiếm hướng khắc phục các khiếm khuyết, sai sót, hoặc bổ sung yêu cầu vào phần mềm.
- Ngày dự kiến kết thúc: dự kiến ngày hoàn thành các sửa chữa, bổ sung theo như được xác định
- Ngày dự định phúc đáp việc xử lý: dự kiến ngày trao đổi với khách hàng để giải quyết những yêu cầu
- Ngày thực sự hoàn thành: ngày thực sự sửa chữa xong những khiếm khuyết hay đã hoàn thành việc bổ sung yêu cầu
- Tình trạng (hiện thời): thể hiện tình trạng của phần mềm tại thời điểm hiện thời (đã chạy tốt hay vẫn đang sửa chữa)
ỨNG DỤNG THỰC TIỄN
Giới thiệu về dự án V.EMIS
V.EMIS – phân hệ quản lý nhà trường là một phần hệ của dự án SREM Với phần mềm này sẽ giúp cho các trường phổ thông tăng khả năng quản lý, giảm bớt công sức cho quá trình quản lý nhưng lại đảm bảo chất lượng quản lý và còn hỗ trợ cho việc thanh tra giám sát của các cấp trên Hình 3.1 thể hiện cấu trúc của phần mềm
Do quy mô lớn và môi trường triển khai đa dạng, phần mềm cần phát triển linh hoạt để đáp ứng yêu cầu bổ sung Nhóm đã chọn mô hình phát triển xoắn ốc, dựa trên mô hình thác nước nhưng với các giai đoạn mềm dẻo và linh hoạt hơn Tính linh hoạt này giúp dự án giải quyết hiệu quả các vấn đề phát sinh từ nhu cầu của người sử dụng, cho phép xác định và đánh giá khả năng đáp ứng yêu cầu mới từ khách hàng.
- Viết tài liệu đặc tả và thiết kế: giai đoạn này được nhóm phát triển thực hiện chính xác đảm bảo đáp ứng yêu cầu của khách hàng
Để đảm bảo chất lượng sản phẩm phát triển, nhóm cần xây dựng các chuẩn đánh giá dựa trên tiêu chuẩn Quốc gia, Quốc tế và đặc thù của dự án, kết hợp với kinh nghiệm thực tế trong phát triển phần mềm Tài liệu chuẩn này sẽ giúp các thành viên trong nhóm hình thành thói quen kiểm soát chất lượng, từ đó đảm bảo rằng sản phẩm được phát triển sẽ đạt tiêu chuẩn chất lượng khi giao cho khách hàng.
- Xác định môi trường làm việc : tổ chức làm việc nhóm và đưa ra quy ước lập trình của nhóm
- Triển khai công việc: thực hiện code, kiểm thử, sửa chữa lỗi, viết tài liệu
- Tích hợp đóng gói chương trình giao cho khách hàng để thực hiện triển khai thí điểm
- Tiếp tục mở rộng các ứng dụng để đáp ứng như cầu tiến hóa của phần mềm, giúp phần mềm có thời gian sống dài.
Môi trường làm việc
Dự án có quy mô lớn và yêu cầu phát triển đồng thời nhiều phân hệ, điều này tạo ra thách thức trong tổ chức Để giải quyết vấn đề này, nhóm phát triển dự án đã quyết định triển khai từng phân hệ một và áp dụng phương pháp làm việc nhóm Nhóm gồm 8 thành viên, mỗi người được phân công công việc cụ thể dựa trên đặc thù của phần mềm, giúp tối ưu hóa quy trình phát triển và triển khai dự án.
Khi phát triển phần mềm theo nhóm, việc thiết lập bảng quy ước lập trình là rất quan trọng để đảm bảo công việc diễn ra đồng bộ và trơn tru Quy ước này không chỉ tạo ra bầu không khí làm việc thoải mái mà còn nâng cao hiệu quả làm việc của các thành viên trong nhóm Để đạt được những điều này, nhóm đã lựa chọn một môi trường làm việc phù hợp.
3.2.1 Tổ chức môi trường làm việc
Dự án đổi mới quy trình quản lý nhà trường được triển khai từ cấp trường đến cấp bộ, với phần mềm hoàn thiện từng bước nhằm tạo ra cơ sở dữ liệu tập trung, chia sẻ giữa các phân hệ và thống nhất cấu trúc để chuẩn hóa thông tin Mỗi cấp cần tập trung vào các nghiệp vụ ổn định và giải quyết tính đa dạng của từng trường, vùng miền Phần mềm phải đơn giản và dễ sử dụng, với giao diện trên nền Windows, phương thức quản trị thống nhất và tận dụng cơ sở hạ tầng chi phí thấp, bao gồm các phiên bản phần mềm miễn phí và mã nguồn mở Điều này giúp nhóm phát triển lựa chọn môi trường phát triển phù hợp, tăng năng suất, dễ bảo trì và mở rộng, đồng thời giảm nhẹ thao tác viết mã cho lập trình viên và cho phép tương tác với các ứng dụng bên ngoài.
Vì vậy nhóm sử dụng các công cụ sau hỗ trợ cho việc phát triển:
- Sử dụng ngôn ngữ lập trình hướng đối tượng là C# theo chuẩn Net Framework 3.5 của Microsoft
- Hệ quản trị CSDL: SQL Express Edition (phiên bản miễn phí của Microsoft) với hệ điều hành XP 32 bit cùng với IDE Visual Studio
- Công cụ hỗ trợ kiểm soát phiên bản Subversion
Phương pháp kiểm thử phần mềm bao gồm kiểm thử đơn vị với NUnit, kiểm thử hộp trắng và hộp đen, cùng với việc sử dụng công cụ log4net để quản lý và ghi lại nhật ký.
Nhóm quyết định sử dụng ngôn ngữ lập trình C# thay vì các ngôn ngữ khác như Java, C hay C++ vì các thành viên đã thành thạo C# và nó phù hợp với xu thế phát triển hiện đại C# nổi bật với sự đơn giản, dễ dàng tích hợp với các công cụ trên nền tảng Windows như MS SQL và Excel Hơn nữa, C# là ngôn ngữ hiện đại, có khả năng xử lý ngoại lệ, thu gom bộ nhớ tự động, hỗ trợ kiểu dữ liệu mở rộng và bảo mật mã nguồn Cuối cùng, C# là ngôn ngữ hướng đối tượng mạnh mẽ, linh hoạt, với ít từ khóa và tính chất hướng mô đun.
Lựa chọn môi trường phát triển phù hợp cho nhóm phát triển là yếu tố quan trọng giúp kiểm soát chất lượng ở từng giai đoạn thực hiện một cách dễ dàng và chính xác Đảm bảo chất lượng trong từng giai đoạn không chỉ nâng cao chất lượng sản phẩm cuối cùng khi bàn giao cho khách hàng mà còn giảm thiểu lỗi trong quá trình triển khai, bảo trì và mở rộng phần mềm Sự tin tưởng từ khách hàng đối với sản phẩm sẽ nâng cao uy tín cho nhóm phát triển, tạo cơ hội cho việc nhận thêm các dự án phần mềm trong tương lai.
Trước khi bắt đầu phát triển, nhóm đã nhận thức rõ tầm quan trọng của việc thiết lập quy ước lập trình Do đó, họ đã đưa ra những quy tắc cụ thể nhằm đảm bảo tính nhất quán và hiệu quả trong quá trình phát triển phần mềm.
Các quy ước lập trình phổ biến
- Kiểu lùi dòng (indent style)
- Kỹ thuật lập trình (programming practices)
- Nguyên tắc lập trình (programming principles)
- Bí quyết lập trình (programming rules of thumb)
- Phong cách lập trình (programming style)
Kiểu lùi dòng (indent style)
- Gióng hàng thẳng theo dấu ngoặc mở đầu tiên (dấu ngoặc phải ở dòng tiếp theo)
- Mỗi lần lùi dòng là 1 ký tự tab (\t), không lùi dòng bằng nhiều phím trắng (Space)
Việc sắp xếp mã nguồn theo cách này giúp làm rõ cấu trúc của nó Các lệnh được bao bọc bởi hai dấu ngoặc mở và đóng tương ứng, đồng thời hai dấu này được căn chỉnh cùng cột trong các dòng riêng biệt, tạo thuận lợi cho việc xác định các cặp dấu ngoặc.
Ví dụ: while (x == y) { something(); somethingelse();
Cách đặt tên (Naming convention)
Quy ước đặt tên là tập hợp các quy tắc lựa chọn ký tự cho định danh của biến, kiểu và hàm trong mã nguồn và tài liệu Việc sử dụng quy ước đặt tên có những lý do căn bản như: tăng tính rõ ràng, dễ hiểu và khả năng bảo trì của mã nguồn.
- Giảm công sức cần cho việc đọc và hiểu mã nguồn
- Tăng mức độ biểu hiện của mã nguồn (ví dụ, không cho phép tên quá dài hoặc viết tắt)
Một số lợi ích từ việc áp dụng quy ước đặt tên là:
- Cung cấp thêm thông tin về việc sử dụng những định danh đang được quan tâm
- Tăng cường tính nhất quán trong toàn đội phát triển
- Cho phép việc dùng các công cụ refactoring tự động/tìm kiếm/thay thế với khả năng lỗi ít nhất
- Tăng tính rõ ràng trong trường hợp nhập nhằng
- Tránh trùng tên nếu sản phẩm từ nhiều tổ chức khác nhau được kết hợp lại…
Quy ước trong nhóm được định nghĩa như sau:
Mỗi vĩ lệnh (macro) là một khai báo hằng số trong các chương trình, cần quán triệt quy ước đặt tên Khác với biến (variable), vĩ lệnh phải được định nghĩa bằng ký tự viết hoa và có ý nghĩa rõ ràng Các từ trong vĩ lệnh được phân cách bởi gạch chân để dễ nhận diện, vì việc sử dụng toàn bộ chữ viết hoa khiến việc tách từ khó khăn Ví dụ từ mã nguồn frmNapAnhHocSinh.cs của VEMIS_Student: public const int IMAGE_RETRIEVAL_PORT = 9050; public const int MAX_SENT_BLOCKSIZE = 1024; public const string IR_SAVE_COMMAND = "SAVE_COMMAND";
ImageRetrieval Save Command public const string IR_VIEW_COMMAND = "VIEW_COMMAND";//
ImageRetrieval View Command public const string IR_OK_ACK = "OK";// OK Acknowlegement public const int MAX_IMAGE_SIZE = 100000;// kich thuoc anh hoc sinh toi da 100 Kbytes
Lệnh đầu tiên xác định số hiệu cổng của IMAGE_RETRIEVAL, một trình trao đổi ảnh giữa máy chủ và máy trạm qua giao thức TCP/IP Sau đó, nó nêu rõ kích thước tối đa của một block dữ liệu có thể gửi giữa các máy.
Biến (variable) được phân biệt rõ ràng với thành phần dữ liệu (data member) trong các lớp (class) và tham số (parameter) trong các hàm Có thể hiểu biến là biến cục bộ (local variable) trong hàm hoặc biến toàn cục (global variable).
Các biến (dù là local hay global) cần tuân thủ quy ước gồm những thành phần sau:
- Tên kiểu dữ liệu (viết tắt bằng chữ thường) Ví dụ: kiểu string → str, int → n (number), mảng [ ] → a…
Mục đích của biến được đặt tên theo quy ước viết liền nhau với ký tự đầu viết hoa, tương tự như quy ước của Microsoft Quy ước này được gọi là LV (local variable) Ví dụ minh họa cho quy ước này là: static void Main().
DataTable dtOrder = GetOrders(); ds.Tables.Add(dtCustomer); ds.Tables.Add(dtOrder); ds.Relations.Add("CustomerOrder", new DataColumn[] { dtCustomer.Columns[0] }, new DataColumn[] { dtOrder.Columns[1] }, true);
System.IO.StringWriter swNoHierarchy = new System.IO.StringWriter(); dtCustomer.WriteXml(swNoHierarchy, XmlWriteMode.WriteSchema, false); PrintOutput(swNoHierarchy, "Customer table, without hierarchy");
System.IO.StringWriter swHierarchy = new System.IO.StringWriter(); dtCustomer.WriteXml(swHierarchy, XmlWriteMode.WriteSchema, true); PrintOutput(swHierarchy, "Customer table, with hierarchy");
Console.WriteLine("Press any key to continue.");
Trong ví dụ trên, các biến cục bộ là
- ds: chỉ có thành phần đầu tiên đại diện cho kiểu DataSet
- dtCustomer: dt (DataTable) + Customer → bảng dữ liệu về khách hàng
- dtOrder: dt + Order → bảng dữ liệu về vận đơn
- swNoHierarchy: sw (StringWriter) + NoHierarchy → ghi chuỗi ra ngoài mà không có cây thế hệ
- swHierarchy: sw (StringWriter) + Hierarchy → ghi chuỗi ra ngoài có cây thế hệ
Khi đặt tên cho biến toàn cục, bạn nên sử dụng tiền tố g_ theo sau là tên biến cục bộ Ví dụ, biến toàn cục g_dtCustomer đại diện cho bảng dữ liệu (dt) về khách hàng (Customer).
Thành phần dữ liệu (data member) trong các lớp có thể được đặt tên theo chuẩn: m_ + LV (m_ là member) Ví dụ sau được trích từ frmNapAnh.cs của
In the declaration region, the variable `m_strFileName` is a private static string within the `frmNapAnh` class, designed to store the file path of a student's image The naming convention includes the prefix 'm_' to indicate its member status, followed by 'str' to denote its string type, and 'FileName' to clarify its purpose.
Thực hiện mô đun hóa các chức năng
Hiện nay, nhóm phát triển đang triển khai phân hệ quản lý học sinh cho dự án, bao gồm các mô đun chính như Quản lý hệ thống, Quản lý hồ sơ và tình hình học tập, cùng với mô đun QuanLyDiemHocSinh Mỗi mô đun này được chia thành các mô đun nhỏ hơn, thực hiện các chức năng cụ thể nhằm nâng cao hiệu quả quản lý học sinh.
- Quản lý các danh mục
- Kết nối máy chủ CSDL
- Xuất dữ liệu lên cấp trên
- Xuất hồ sơ trường Menu Khối học/lớp học có các thành phần:
- Nhập danh sách học sinh trúng tuyển
- Lập danh sách lớp học từng khối
- Phân học sinh vào lớp
- Sắp xếp danh sách học sinh
- Kết chuyển học sinh lên lớp
- Xuất hồ sơ ra file Excel
- Nạp hồ sơ từ file Excel
- Nạp và sửa hồ sơ ban đầu
- Đăng ký nghỉ học dài hạn
- Đăng ký đi học trở lại
- Đăng ký các tham số thường dùng Ban học/môn học
- Đăng ký môn miễn giảm
- Đăng ký môn khuyến khích
- Đăng ký hệ ngoại ngữ Kiểm tra và thi
- Xếp phòng thi cho học sinh
- Nhập học sinh bỏ thi
- Xuất hồ sơ để nhập điểm
- Nhập điểm thi Thống kê báo cáo và tìm kiếm
- Các biểu mẫu thống kê số lượng học sinh
Mô đun hóa các chức năng giúp phân chia công việc một cách rõ ràng, tránh chồng chéo và thiếu sót Việc lưu trữ tài liệu phân chia công việc giúp quản lý dự án dễ dàng theo dõi tiến độ và kiểm soát lỗi Mô đun hóa đóng vai trò quan trọng trong phát triển dự án phần mềm quy mô lớn, do đó cần kiểm soát chặt chẽ để đảm bảo yêu cầu và nâng cao chất lượng sản phẩm.
Việc lựa chọn môi trường làm việc phù hợp và mô đun hóa các chức năng của phần mềm quy mô lớn là yếu tố then chốt trong việc phát triển phần mềm chất lượng Đồng thời, việc triển khai và phát triển song song giúp giải quyết những khó khăn trong quá trình phát triển Kiểm soát tốt giai đoạn này không chỉ nâng cao chất lượng phần mềm mà còn tạo nền tảng vững chắc cho các bước phát triển tiếp theo trong sản xuất phần mềm.
Kết quả khi áp dụng kỹ thuật kiểm thử
Nhờ nắm vững đặc điểm và lợi ích của kỹ thuật kiểm thử, nhóm phát triển dự án VEMIS đã linh hoạt áp dụng các phương pháp kiểm thử khác nhau, góp phần quan trọng vào việc kiểm soát chất lượng trong quá trình phát triển phần mềm Kết quả thu được từ việc áp dụng này đã mang lại hiệu quả tích cực cho sản phẩm phần mềm mà nhóm thực hiện.
Kiểm thử đơn vị là một phần quan trọng trong quy trình phát triển phần mềm, giúp đánh giá chất lượng nội tại của sản phẩm Mặc dù thời gian dành cho kiểm thử đơn vị có thể tốn kém, nhưng nó là cần thiết để kiểm soát chất lượng và tránh những khiếm khuyết không đáng có Chi phí kiểm thử tăng theo quá trình phát triển, nhưng một kiểm thử đơn vị hiệu quả có thể giảm bớt các kiểm thử tiếp theo, từ đó giảm chi phí sản xuất và nâng cao chất lượng sản phẩm Sản phẩm với ít khiếm khuyết khi giao cho khách hàng sẽ tạo niềm tin và thúc đẩy sự hợp tác giữa nhà phát triển và khách hàng.
Mặc dù kiểm thử đơn vị đã thành công, điều này không đảm bảo rằng phần mềm sẽ không gặp lỗi khi các đơn vị được tích hợp Do đó, việc thực hiện kiểm thử tích hợp là cần thiết cho nhóm phát triển phần mềm.
Kiểm thử tích hợp đóng vai trò quan trọng trong việc đánh giá chất lượng bên ngoài của phần mềm Khi đạt được các tiêu chí chất lượng bên ngoài, điều này khẳng định phần mềm đáp ứng yêu cầu chất lượng cần thiết Sự đáp ứng này ảnh hưởng lớn đến trải nghiệm sử dụng Kiểm soát quy trình kiểm thử tích hợp đồng nghĩa với việc kiểm soát chất lượng bên ngoài của sản phẩm, từ đó góp phần nâng cao chất lượng tổng thể của phần mềm.
Kiểm thử hồi quy là bước quan trọng sau khi sửa chữa lỗi trong phần mềm, nhằm đảm bảo rằng các lỗi cũ không xuất hiện trở lại và không phát sinh lỗi mới Việc lập trình viên tác động vào cơ sở dữ liệu (CSDL) có thể gây ra sự không tương thích với các mô đun khác, dẫn đến lỗi mới Do đó, nhóm phát triển cần đánh giá mức độ nghiêm trọng của lỗi và xác định ảnh hưởng của việc sửa chữa đến các mô đun liên quan để đưa ra giải pháp hợp lý Nếu không kiểm soát tốt, có thể xảy ra bùng nổ lỗi, ảnh hưởng nghiêm trọng đến chất lượng sản phẩm Vì lý do này, kiểm thử hồi quy là không thể thiếu trong quy trình phát triển phần mềm Sau khi thực hiện kiểm thử hồi quy và xác nhận mô đun hoạt động ổn định, cần ghi chú kết quả vào bảng danh sách lỗi.
Kiểm thử chấp nhận là bước quyết định xem phần mềm có được chấp nhận hay cần sửa chữa và kiểm thử lại Trong giai đoạn này, tất cả lỗi từ các thành viên trong từng mô-đun chức năng được ghi lại dưới dạng bảng danh sách lỗi Bảng này không chỉ là tài liệu quan trọng mà còn được thông báo cho các bên liên quan, giúp ích cho nhóm phát triển trong quá trình khắc phục và cải thiện phần mềm.
- Giúp các thành viên có kinh nghiệm hơn trong lập trình
- Tránh được các lỗi trong khi lập trình
- Biết được lỗi xuất hiện ở vị trí nào, thuộc trách nhiệm của ai
- Biết được phần nào đã thực hiện kiểm thử giúp việc kiểm thử không bị trùng lặp hoặc có bỏ qua không kiểm thử
Do thời gian và điều kiện hạn chế, tôi xin trích dẫn một số lỗi từ tài liệu kiểm thử của nhóm phát triển để minh họa cho vấn đề đã nêu.
TT Ngày phát hiện vấn đề (ghi cụ thể hiện tượng)
Mô tả lỗi Loại (câu hỏi/yêu cầu)
Thời hạn dự định xử lý
Ngày dự định kết thúc
Ngày dự định phúc đáp việc xử lý
Ngày thực sự hoàn tất
2 Lập danh sách lớp học theo khối==> chọn lớp học
3 Đăng ký môn chuyên==> báo lỗi hộp thoại xuất hiện > nhấn chuột 4 lần thì có bảng nhập môn chuyên nhưng không nhập được
2 Lập danh sách lớp học theo khối==> chọn lớp học
3 Tạo danh sách lớp tự động==> nhập theo yêu cầu
Cột tên lớp học không có form chuẩn, có thể nhập số ký tự bất kỳ không giống như đã có
1 Thực hiện nhập điểm và tính điểm tổng kết môn học
Bảng điểm in ra không đúng như yêu cầu
Yêu cầu Trung bình 26/07/11 Lình 01/08/11 Hiệp 01/08/11 01/08/11 01/08/11 OK
Bảng 3.1: Trích một số lỗi trong tài liệu lỗi
TIEU LUAN MOI download : skknchat@gmail.com
Danh sách lỗi trong tài liệu kiểm thử đã giúp giảm số lượng lỗi của các thành viên trong nhóm phát triển theo thời gian Sự giảm thiểu này là kết quả của việc các thành viên kiểm soát chất lượng phần mềm một cách nghiêm ngặt thông qua các kỹ thuật hỗ trợ kiểm soát và tài liệu ghi lỗi Dưới đây là thống kê số lỗi gặp phải của các thành viên trong hai giai đoạn phát triển khác nhau để minh chứng cho điều này.
STT Thành viên Số lỗi
Bảng 3.2: Thống kê số lỗi của các thành viên ở hai giai đoạn phát triển
Việc áp dụng các kỹ thuật hỗ trợ kiểm soát chất lượng phần mềm trong quá trình phát triển đóng vai trò quan trọng, giúp nâng cao hiệu quả và đảm bảo chất lượng sản phẩm cuối cùng Kết quả thu được cho thấy sự cần thiết của những kỹ thuật này trong việc tối ưu hóa quy trình phát triển phần mềm.
Áp dụng kỹ thuật kiểm soát phiên bản
Trong quá trình phát triển và triển khai thí điểm phần mềm quản lý cấp trường, nhóm phát triển vẫn tiếp tục hỗ trợ quản lý ở các cấp phòng, sở và bộ Đồng thời, các kỹ thuật kiểm soát chất lượng được áp dụng để đảm bảo sản phẩm đạt tiêu chuẩn.
Phần mềm có khả năng mở rộng linh hoạt, giúp việc bổ sung chức năng trở nên dễ dàng trong quá trình phát triển Để đảm bảo tính cập nhật, các thành viên trong nhóm phát triển cần thường xuyên cập nhật dữ liệu Trong quá trình phát triển, kỹ thuật kiểm soát chất lượng phần mềm quan trọng mà đội ngũ sử dụng là Subversion (SVN) Nhóm phát triển của viện đã thực hiện các bước cần thiết để tối ưu hóa quy trình này.
Trước tiên, trên máy chủ cài đặt Subversion server, cần thiết lập các mục quan trọng để hỗ trợ quản lý và phân quyền cho các thành viên trong nhóm phát triển.
- Trên máy cá nhân thì cài đặt TortoiseSVN để có thể trao đổi dữ liệu với server
Trên mỗi client, cần tạo hai thư mục: một thư mục để cập nhật dữ liệu từ server và một thư mục riêng để phát triển cá nhân, nhằm phục vụ cho việc commit dữ liệu lên server.
Sau khi cài đặt và tạo các thư mục cần thiết, các thành viên đã kết nối với máy chủ bằng tài khoản được cấp và bắt đầu thực hiện công việc của mình, tạo ra các file cần thiết trong mô đun của họ.
Khi máy chủ và máy khách đã hoàn tất cài đặt phần mềm ứng dụng và tạo các thư mục cần thiết, chúng sẽ giao tiếp qua mạng nội bộ dựa trên tài khoản và quyền truy cập được cấp.
Các thành viên cần thực hiện thêm, bớt, sửa, xóa trên các file trong thư mục phát triển và commit lên server khi hoàn thiện Trước khi commit, cần cập nhật để tránh xung đột Mỗi lần commit sẽ tạo phiên bản mới trên Repository, do đó cần kiểm tra file cẩn thận trước khi thực hiện Quyền commit phải được cấp bởi người quản trị; nếu không có quyền, bạn không thể commit tài liệu Chỉ những file sử dụng chung mới nên được commit, trong khi file sử dụng riêng không nên Subversion sẽ lưu lại một số hình ảnh khi thực hiện update và commit trên Repository của server.
Nhấp chuột phải vào file hoặc thư mục cần cập nhật, sau đó chọn "SVN Update" Một cửa sổ sẽ xuất hiện, và bạn chỉ cần đợi cho quá trình cập nhật thông tin hoàn thành.
Hình 3.2: Danh sách các file Update
Nhấn OK để hoàn tất quá trình cập nhật, và bây giờ client đã sở hữu phiên bản mới nhất của thư mục được chọn trong quá trình phát triển phần mềm của đội.
Nếu bạn muốn biết ai đã thực hiện thay đổi các thư mục đó ta nhấn chọn vào mục
Bảng "Show log" hiển thị tên, thời gian và phiên bản của người thực hiện commit các thay đổi, đồng thời cho biết phần nào được thêm, phần nào bị xóa và phần nào đã thay đổi, cùng với thời gian thực hiện những thay đổi này.
Hình 3.3: Chi tiết thay đổi
Việc thực hiện thao tác này sẽ giúp các thành viên trong nhóm nắm bắt những thay đổi một cách dễ dàng và liên tục Điều này đảm bảo rằng họ luôn có thông tin kịp thời để xử lý công việc hiệu quả.
Nhắp chuột phải vào thư mục hoặc file cần commit chọn SVN commit sẽ xuất hiện
Hình 3.4: Các file được chọn Commit
Nhìn vào cửa sổ trên ta thấy có 4 file được chọn để commit Nhấn chọn OK thì bảng sau xuất hiện:
Hình 3.5: Chi tiết thay đổi khi commit
Cửa sổ trên hiển thị 1 file thêm vào, 1 file bị xóa và 2 file thay đổi Để hoàn thành quá trình commit ta chọn OK
Trong quá trình gửi file lên server, đội test đã cung cấp danh sách các lỗi gặp phải Nhờ vào công cụ kiểm soát chất lượng Subversion, quản trị viên và các thành viên phát triển có thể phân tích lỗi dựa trên danh sách này Họ dễ dàng xác định lỗi thuộc về thành viên nào, trong file nào và vị trí cụ thể ra sao chỉ với thao tác nhấp chọn vào lỗi cần kiểm tra.
B1: chạy phân hệ Student B2: Chọn frmMain.cs
To locate the error, right-click on the error category frmSapXepDanhSachHocSinh and select "Go to Definition." This action will display the section of the program where the error occurred within the namespace VEMIS_Student.GUI.
Để thực hiện cập nhật, bạn cần vào thư mục Student trong thư mục Update, không phải trong thư mục phát triển Tiếp theo, chọn GUI và tìm đến file có tên frmSapXepDanhSachHocSinh, sau đó nhấp chuột phải, chọn TortoiseSVN và tiếp theo chọn Show log Khi đó, một cửa sổ sẽ xuất hiện.
Hình 3.6: Tên thành viên sửa chữa
Cửa sổ này cho ta thấy tên thành viên trong đội tham gia sửa chữa và thời điểm thành viên đó đưa bản sửa lên
B5: Nhắp chuột vào thành viên sửa đổi chọn mục thành viên đó thay đổi
nhắp phải chuột vào tên file chọn Show changes thì bảng sau xuất hiện
Hình 3.7: Hiển thị những thay đổi của file
Cửa sổ bên trái hiển thị các dòng đã bị xóa trong bản trước đó, trong khi cửa sổ bên phải cho thấy các dòng mới được thêm vào.