Untitled ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM Bài giảng cho sinh viên ngành Công nghệ thông tin Đỗ Thị Bích Ngọc Hà Nội 2020 2 MỞ ĐẦU Trước những thách thức trong quá trình phát triển phần mềm, việc đảm bảo ch[.]
GIỚI THIỆU ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM
Khái niệm phần mềm
Trước khi khám phá về đảm bảo chất lượng phần mềm, chúng ta cần hiểu khái niệm cơ bản về phần mềm Phần mềm được định nghĩa là tập hợp các thành phần bao gồm mã nguồn, dữ liệu, hướng dẫn và các tài nguyên khác tạo thành các chương trình và hệ thống giúp máy tính thực hiện các tác vụ cụ thể.
• Dữ liệu cần thiết cho sự vận hành của hệ thống
Các thành phần phần mềm có chức năng riêng biệt, và chất lượng của từng thành phần đóng vai trò quan trọng trong việc nâng cao chất lượng tổng thể của phần mềm Đặc biệt, các yếu tố này ảnh hưởng trực tiếp đến quá trình bảo trì phần mềm, giúp đảm bảo hệ thống hoạt động ổn định và dễ dàng nâng cấp Việc quản lý chất lượng các thành phần phần mềm là yếu tố then chốt để xây dựng phần mềm ổn định, bền vững và tối ưu hóa hiệu suất.
• Chương trình máy tính được cần thiết là hiển nhiên vì chúng giúp máy tính vận hành thực thi các yêu cầu ứng dụng
Các thủ tục cần thiết để xác định thứ tự và lịch trình của một chương trình khi thực thi là yếu tố quan trọng để đảm bảo hoạt động diễn ra theo kế hoạch Phương thức triển khai các thủ tục này giúp kiểm soát quá trình thực thi phần mềm một cách hiệu quả, đồng thời phân định rõ trách nhiệm của các người chịu trách nhiệm trong việc đảm bảo các hoạt động cần thiết được thực hiện đúng thời điểm Việc này đảm bảo phần mềm hoạt động ổn định, chính xác và đáp ứng các yêu cầu đặt ra trong quá trình vận hành.
Trong quá trình phát triển phần mềm, nhiều loại tài liệu khác nhau là cần thiết để hỗ trợ người phát triển, người sử dụng và đội ngũ bảo trì Tài liệu phát triển như báo cáo yêu cầu, báo cáo thiết kế và mô tả chương trình giúp thúc đẩy sự phối hợp và cộng tác hiệu quả giữa các thành viên trong nhóm, đồng thời tạo điều kiện thuận lợi cho việc rà soát và kiểm tra các sản phẩm lập trình và thiết kế Tài liệu sử dụng, thường là hướng dẫn người dùng, cung cấp mô tả chi tiết về ứng dụng và các phương pháp phù hợp để khai thác phần mềm hiệu quả Trong khi đó, tài liệu bảo trì dành cho đội ngũ phát triển giúp cung cấp tất cả các thông tin cần thiết về mã nguồn, cấu trúc các module và công việc liên quan, hỗ trợ quá trình tìm nguyên nhân lỗi, thực hiện các thay đổi hoặc mở rộng chức năng của phần mềm đã phát hành.
Dữ liệu cần thiết bao gồm các tham số đầu vào, mã nguồn và danh sách tên phù hợp với phần mềm để hướng dẫn người dùng thao tác chính xác với hệ thống Chuẩn dữ liệu thử nghiệm đóng vai trò quan trọng trong việc xác định các thay đổi không mong muốn trong mã nguồn hoặc dữ liệu phần mềm đã xảy ra, giúp dự đoán và giảm thiểu các sự cố phần mềm tiềm ẩn Việc sử dụng dữ liệu chuẩn đảm bảo quá trình kiểm thử hệ thống diễn ra hiệu quả, nâng cao độ tin cậy và chất lượng phần mềm.
Các nguyên nhân gây ra lỗi phần mềm
1.2.1 Một số ví dụ điển hình về lỗi phần mềm
Lỗi phần mềm đã gây thiệt hại hàng triệu đô la và ảnh hưởng đến tính mạng con người, thể hiện mức độ nghiêm trọng và đa dạng của các vấn đề phần mềm Để hiểu rõ hơn về những rủi ro này, bài viết giới thiệu 10 lỗi phần mềm nổi tiếng nhất trong ngành công nghiệp công nghệ thông tin.
Hình 1-0-1: Vụ nổ Ariane 5 do lỗi tràn số khi tính toán
Arian 5 là chiếc thứ năm trong loạt tàu vũ trụ dân dụng Ariane của châu Âu dùng để phóng vệ tinh vào không gian Vào ngày 4 tháng 6 năm 1996 ở Kourou, Guiana của Pháp, chiếc Ariane 5 không người lái đã phát nổ chỉ khoảng 40 giây sau khi phóng Chiếc tên lửa trị giá 500 triệu đô la này đã phát nổ do một lỗi phần mềm phổ biến được biết đến dưới tên gọi Integer Overflow Lỗi này đã xảy ra trong quá trình thực hiện chuyển đổi dữ liệu từ số floating point 64-bit sang giá trị số integer16-bit Số floating point đã được chuyển đổi có giá trị lớn hơn số có thể được biểu diễn bởi một số integer16-bit
2 Lỗi phần mềm tên lửa Patriot
Hình 1-0-2: Hệ thống lá chắn tên lửa phán đoán sai vị trí do lỗi làm tròn số
Ngày 25 tháng 2 năm 1991 trong Chiến tranh vùng Vịnh, hệ thống tên lửa Patriot bỗng dưng đã không theo dõi và đánh chặn một tên lửa Scud đang tấn công một doanh trại của Mỹ Theo Cơ quan Trách nhiệm Giải trình Chính phủ Hoa Kỳ, phần mềm đã bị trễ và đã không theo dõi việc phóng tên lửa trong thời gian thực, do đó nó đã để tên lửa của Iraq có cơ hội vượt qua và phát nổ trước khi có thể làm bất cứ điều gì để ngăn chặn nó
Mỹ đã có 28 người thiệt mạng và 100 người bị thương sau sự cố này
Y2K là viết tắt của Year 2000 và được gọi là “lỗi thiên niên kỷ” Vào cuối những năm
Lỗi Y2K, hay lỗi phải chuyển đổi ngày tháng năm trong hệ thống máy tính, là một trong những mối lo ngại lớn khi thế giới chờ đợi khả năng máy bay va chạm, tàu vũ trụ gặp sự cố hoặc thị trường chứng khoán sụp đổ Nguyên nhân chính là do các hệ thống quản lý thời gian chỉ sử dụng hai chữ số để biểu thị năm, ví dụ như 70 cho năm 1970 và 99 cho năm 1999, nhằm mục đích tiết kiệm bộ nhớ.
Khi gần đến năm 2000, các lập trình viên nhận ra rằng máy tính có thể không biểu diễn chính xác năm 2000 do hạn chế của định dạng dữ liệu, với 00 thường dùng để biểu diễn năm 1900 Điều này có thể gây ra lỗi trong các hoạt động lập trình và tự động hàng ngày hoặc hàng năm của hệ thống Vào ngày 31 tháng 12 năm 1999, chuyển sang ngày 1 tháng 1 năm 2000, máy tính có thể hiểu nhầm là từ năm 1900 hoặc gây ra lỗi hệ thống, gây ảnh hưởng lớn đến hoạt động của các hệ thống máy tính toàn cầu.
31 tháng 12 năm 1999, chuyển sang ngày 1 tháng 1 năm 1900
Các ngân hàng tính lãi suất hàng ngày để xác định khoản phí mà khách hàng, như cá nhân hoặc doanh nghiệp, phải trả khi vay tiền Tuy nhiên, việc tính lãi theo ngày khiến ngân hàng phải đối mặt với các vấn đề thực sự về quản lý và chính xác trong việc xác định phí vay Thay vì áp dụng tỷ lệ lãi suất hàng ngày, các ngân hàng thường tính lãi dựa trên tỷ lệ lãi suất cho gần 100 năm, điều này giúp tối ưu hóa quá trình tính toán và đảm bảo chính xác hơn trong các giao dịch tài chính dài hạn Việc hiểu rõ cách tính lãi này rất quan trọng để khách hàng có thể nắm rõ các khoản phí vay và ngân hàng giảm thiểu rủi ro liên quan đến sai số trong tính toán lãi suất.
Các trung tâm công nghệ như nhà máy điện là những đối tượng bị đe dọa bởi lỗi Y2K, bởi chúng phụ thuộc vào hệ thống máy tính để đảm bảo an toàn và thực hiện công tác bảo trì Nếu không có ngày chính xác, các tính toán liên quan đến áp lực nước hoặc mức độ bức xạ có thể bị mất đi, dẫn đến nguy hiểm cho cư dân gần đó.
Giao thông vận tải phụ thuộc vào thời gian và ngày tháng chính xác để duy trì hoạt động trơn tru Các hãng hàng không đặc biệt dễ bị ảnh hưởng khi hệ thống máy tính lưu trữ thông tin chuyến bay gặp sự cố, gây ra tình trạng đảo lộn toàn bộ lịch trình bay.
Y2K ban đầu khiến nhiều người lo lắng về khả năng gây ra các sự cố nghiêm trọng trong hệ thống máy tính trên toàn thế giới Tuy nhiên, cuối cùng, Y2K đã không gây ra hậu quả nghiêm trọng nào, nhờ vào nỗ lực chuẩn bị kỹ lưỡng của các nhà phát triển phần mềm Để đảm bảo hệ thống hoạt động ổn định, các kỹ sư cần mất một thời gian để khắc phục triệt để lỗi này, giúp tránh các sự cố lớn xảy ra sau năm 2000.
4 Khoản tiền gửi 92 nghìn triệu triệu đô la trên PayPal
Vào tháng 6 năm 2013, Chris Reynolds bất ngờ khi kiểm tra tài khoản PayPal của mình và phát hiện số dư tài khoản của anh đã tăng lên đến 92.233.720.368.547.800 USD, một con số bất ngờ và khó tin Sự kiện này khiến anh cảm thấy hoảng hốt và choáng ngợp trước số tiền khổng lồ có trong tài khoản PayPal của mình Trước đó, Reynolds là một nhân viên tại PR Pennsylvania, nhưng số dư tài khoản của anh đã vượt xa mọi giới hạn thông thường Tài khoản PayPal này trở thành đề tài gây chú ý lớn trên truyền thông khi xuất hiện số dư kỳ lạ và khó hiểu như vậy.
Số tiền này đã được ghi có vào tài khoản PayPal của Reynolds do một lỗi phần mềm, khiến anh trở thành người giàu nhất thế giới PayPal thừa nhận đây là lỗi kỹ thuật của họ và đã đề nghị tặng một khoản tiền chưa được công bố cho Reynolds.
5 YouTube phải nâng cấp bộ đếm vì Gangnam Style
Năm 2014, YouTube gặp sự cố liên quan đến video âm nhạc Gangnam Style của Psy, khi số lượt xem vượt qua giới hạn của bộ đếm 32-bit YouTube được xây dựng trên nền tảng 32-bit, giới hạn số lượt xem mỗi video trong khoảng từ -2.147.483.648 đến 2.147.483.647, tức là khoảng 2.15 tỷ lượt xem Tuy nhiên, video Gangnam Style đã phá vỡ giới hạn này khi vượt qua mốc 2.147.483.647 lượt xem, khiến hệ thống không thể hiển thị chính xác số lượt xem của nó Có thể nguyên nhân là do các bậc phụ huynh liên tục cho con, cháu xem để dụ ăn cháo, ăn cơm, khiến số lượt xem tăng đột biến và trở thành một hiện tượng đặc biệt trên YouTube.
YouTube đã chia sẻ rằng họ không bao giờ nghĩ rằng sẽ có video có lượt xem vượt quá một số nguyên 32-bit, thể hiện sự phát triển vượt bước của nền tảng chia sẻ video này.
Hình 1-0-3: lỗi tràn số do số lượt xem bài Gangnam style quá lớn
Google sau đó đã sửa lỗi YouTube này bằng cách sử dụng một số nguyên 64-bit để lưu số lượt xem của mỗi video
6 Lỗi tính toán của Windows Calculator Đây là một lỗi trong Calculator của Windows, tồn tại ở các phiển bản Windows XP, Windows Vista, Windows 7 Windows 8 Lỗi xảy ra khi ta tính biểu thức: sqrt(4) -2 (lấy căn bậc hai của 4 rồi trừ đi 2) Câu trả lời đáng ra phải là là 0 nhưng máy tính của Windows không cho ra kết quả 0 Ở chế độ Standard, kết quả sẽ là -1.068281969439142e-19 (hình bên dưới) Ở chế độ Scientific, kết quả sẽ là 8.1648465955514287168521180122928e-39 (hình bên dưới)
Hình 1-0-4: Lỗi tính toán sai trên Calculator Điều tương tự cũng xảy ra với các số khác như: sqrt(9) -3, sqrt(16) -4, …
Tuy nhiên trên Windows 10 thì lỗi này đã được fix
Năm 2038 là một vấn đề lỗi thời gian tương tự như vấn đề Y2K đã từng diễn ra trước đó, gây lo ngại về khả năng hoạt động của các hệ thống máy tính Các máy tính chạy hệ điều hành 32-bit trên toàn thế giới có thể gặp sự cố hoặc ngừng hoạt động vào ngày 19/01/2038 do giới hạn về khả năng xử lý ngày tháng Đây là mối đe dọa cần được các nhà phát triển và tổ chức công nghệ quan tâm để đảm bảo an toàn dữ liệu và vận hành liên tục của hệ thống.
Đảm bảo chất lượng phần mềm
Theo IEEE, chất lượng phần mềm được định nghĩa như sau :
Chất lượng phần mềm là:
• Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được yêu cầu đã đặc tả
• Mức độ mà một hệ thống, thành phần hoặc một tiến trình đạt được những nhu cầu hay mong đợi của khách hàng hoặc người sử dụng
Ban đầu, đảm bảo chất lượng phần mềm nhằm mục tiêu đáp ứng các yêu cầu đề ra Tuy nhiên, trong quá trình phát triển phần mềm thực tế, tồn tại nhiều ràng buộc phức tạp yêu cầu người phát triển phải tối ưu hóa công tác quản lý dự án.
Đảm bảo chất lượng phần mềm là một tập hợp các hoạt động có kế hoạch và hệ thống nhằm đảm bảo sự tin cậy của quy trình phát triển hoặc bảo trì phần mềm Các hoạt động này giúp đảm bảo rằng sản phẩm phần mềm phù hợp với các yêu cầu chức năng, kỹ thuật và quản lý, đồng thời giữ cho dự án trong phạm vi ngân sách và thời gian đã đề ra.
1.3.2 Mục tiêu đảm bảo chất lượng phần mềm
Phát triển phần mềm luôn đi đôi với hoạt động bảo trì, vì vậy việc đảm bảo chất lượng phần mềm có vai trò quan trọng trong quá trình duy trì và nâng cao hiệu suất hệ thống Các mục tiêu đảm bảo chất lượng phần mềm theo từng giai đoạn phát triển và bảo trì đều được xác định rõ ràng, nhằm giảm thiểu lỗi, nâng cao tính ổn định và đáp ứng yêu cầu của người dùng Việc liên tục kiểm tra, sửa lỗi và tối ưu phần mềm chính là chìa khóa để duy trì chất lượng và kéo dài tuổi thọ của phần mềm trong quá trình vận hành.
- Phát triển phần mềm (hướng tiến trình)
1 Đảm bảo một mức độ chấp nhận được rằng phần mềm sẽ thực hiện được các yêu cầu chức năng
2 Đảm bảo một mức đọ cấp nhận được rằng phần mềm sẽ đáp ứng được các yêu cầu về lịch biểu và ngân sách
3 Thiết lập và quản lý các hoạt động để cải thiện và nâng cao hiệu quả của phát triển phần mềm và các hoạt động SQA
- Bảo trì phần mềm (hướng sản phẩm)
1 Đảm bảo một mức độ chấp nhận được rằng các hoạt động bảo trì phần mềm sẽ đáp ứng được các yêu cầu chức năng
2 Đảm bảo một mức đọ cấp nhận được rằng các hoạt động bảo trì phần mềm sẽ đáp ứng được các yêu cầu về lịch biểu và ngân sách
3 Thiết lập và quản lý các hoạt động để cải thiện và nâng cao hiệu quả của bảo trì phần mềm
1.3.3 Xác minh, thẩm định và đánh giá chất lượng
Ba khía cạnh đảm bảo chất lượng của sản phẩm phần mềm gồm Verification, Validation, và Qualification
Quá trình xác minh là bước quan trọng để đánh giá hệ thống hoặc thành phần nhằm đảm bảo rằng các sản phẩm phát triển trong từng giai đoạn đáp ứng đầy đủ các điều kiện đặt ra từ đầu dự án Việc xác minh giúp đảm bảo chất lượng và tính đúng đắn của sản phẩm, hỗ trợ quá trình phát triển phần mềm hiệu quả hơn Đây là yếu tố then chốt trong quản lý dự án công nghệ, giúp giảm thiểu rủi ro và nâng cao độ tin cậy của hệ thống.
Validation là quá trình đánh giá hệ thống hoặc thành phần trong suốt quá trình phát triển hoặc sau khi hoàn thành để xác định xem nó có đáp ứng các yêu cầu đã xác định hay không, đảm bảo chất lượng và tính đúng đắn của sản phẩm.
• Qualification: quá trình xác định một hệ thống hoặc một thành phần có phù hợp với việc sử dụng hay không
Verification, theo định nghĩa của IEEE, là quá trình kiểm tra tính nhất quán của sản phẩm đang phát triển so với các phiên bản đã hoàn thiện ở các giai đoạn trước Quá trình này được thực hiện bởi người thẩm tra sau khi quá trình phát triển đã kết thúc, với giả định rằng tất cả các giai đoạn trước đã được hoàn thành đúng theo kế hoạch hoặc đã chỉnh sửa các lỗi được phát hiện Verification giúp đảm bảo rằng sản phẩm mới phù hợp với các tiêu chuẩn và yêu cầu đã đặt ra ban đầu, nâng cao chất lượng và độ chính xác của sản phẩm cuối cùng.
Validation miêu tả sự quan tâm của khách hàng, bằng cách thẩm tra những yêu cầu gốc của họ
Trong quá trình qualification, trọng tâm được đặt vào các khía cạnh hoạt động, đặc biệt là vấn đề bảo trì hệ thống Việc phát triển và tài liệu hóa các thành phần phần mềm theo chuẩn, kiểu dáng và cấu trúc chuyên nghiệp sẽ giúp dễ dàng bảo trì hơn so với những thành phần sử dụng mã nguồn không quen thuộc.
Người lên kế hoạch cần phải xác định xem những khía cạnh nào nên được sát hạnh trong mỗi hoạt động đảm bảo chất lượng phần mềm
Xác minh là hoạt động mang tính kỹ thuật cao hơn, dựa trên kiến thức về yêu cầu và đặc tả phần mềm để đảm bảo tính chính xác Trong khi đó, xác nhận thường phụ thuộc vào kiến thức chuyên môn trong lĩnh vực liên quan, như kiến thức về ứng dụng của phần mềm Ví dụ, việc xác nhận phần mềm dành cho máy bay đòi hỏi sự hiểu biết từ kỹ sư hàng không và phi công để đảm bảo tính phù hợp và an toàn của sản phẩm.
Cụm từ IV & V (independent verification and validation) nghĩa là xác nhận và xác minh độc lập, yêu cầu đánh giá phải được thực hiện bởi người không phải là lập trình viên Đội IV & V có thể thuộc dự án, cùng công ty hoặc một tổ chức độc lập khác nhằm đảm bảo tính khách quan và độc lập trong quá trình xác nhận Quá trình IV & V thường bắt đầu sau khi dự án kết thúc để đảm bảo chất lượng phần mềm, và thường do các chuyên gia trong lĩnh vực thực hiện thay vì người phát triển phần mềm để đảm bảo tính khách quan và đáng tin cậy.
Các tiêu chí chất lượng
Nhiều tác giả đã nghiên cứu về các yếu tố chất lượng phần mềm dựa trên yêu cầu của nó Mặc dù quan niệm về đảm bảo chất lượng phần mềm đã thay đổi theo thời gian, mô hình các yếu tố đảm bảo chất lượng phần mềm của McCall từ những năm 1970 vẫn giữ vai trò tham chiếu chính Các mô hình như của Evans, Marciniak, Deutsch và Willis đã được phát triển sau McCall, chủ yếu để bổ sung hoặc chỉnh sửa các yếu tố chất lượng Theo McCall, các yếu tố chất lượng phần mềm được chia thành ba loại chính, giúp định hướng rõ ràng trong quá trình đảm bảo chất lượng phần mềm.
• Các yếu tố hoạt động của sản phẩm bao gồm tính chính xác, tin cậy, hiệu quả, tính toàn vẹn, sử dụng được
• Các yếu tố rà soát bao gồm tính bảo trì, linh hoạt, có thể test được
• Các yếu tố chuyển giao bao gồm tính khả chuyển, có khả năng sử dụng lại, có khả năng giao tác
Hình 1-0-5: Cây mô hình tiêu chí chất lượng phần mềm theo MCCall
Chi tiết các thuộc tính được phân tích như sau :
(1) Các yếu tố vận hành sản phẩm : Sự chính xác, độ tin cậy, tính hiệu quả, tính toàn vẹn và khả năng sử dụng được :
Trong hệ thống phần mềm, yêu cầu về độ chính xác đóng vai trò quan trọng và được xác định rõ ràng qua danh sách các đầu ra cần thiết, như màn hình hiển thị số dư khách hàng trong hệ thống kế toán bán hàng Các đặc tả đầu ra thường mang tính đa chiều, gồm nhiệm vụ đầu ra như in hóa đơn bán hàng hoặc đèn báo động đỏ khi nhiệt độ vượt quá 250 độ F, cùng với các yếu tố như độ chính xác yêu cầu dễ bị ảnh hưởng bởi các lỗi tính toán hoặc dữ liệu không chính xác Ngoài ra, tính đầy đủ của thông tin đầu ra cũng rất quan trọng và có thể bị ảnh hưởng bởi dữ liệu thiếu sót, trong khi đó, tính kịp thời của thông tin (up-to-dateness) phụ thuộc vào thời gian giữa sự kiện và quá trình xem xét hệ thống Độ sẵn sàng của thông tin còn được đo bằng thời gian đáp ứng, tức là thời gian cần thiết để truy cập các thông tin yêu cầu, và các tiêu chuẩn về mã hóa cũng như viết tài liệu cho hệ thống phần mềm cũng đóng vai trò không nhỏ trong việc đảm bảo chất lượng.
• Độ tin cậy : Các yêu cầu về độ tin cậy giải quyết các lỗi để cung cấp dịch vụ
Chúng xác định tỷ lệ lỗi hệ thống phần mềm tối đa cho phép, bao gồm các lỗi có thể ảnh hưởng đến toàn bộ hệ thống hoặc chỉ một số chức năng riêng biệt Việc này giúp đảm bảo chất lượng phần mềm, giảm thiểu rủi ro vận hành và nâng cao trải nghiệm người dùng Tiêu chuẩn này đóng vai trò quan trọng trong quy trình kiểm thử và phát triển phần mềm, đảm bảo hệ thống hoạt động ổn định, tin cậy.
Tính hiệu quả của hệ thống phần mềm đảm bảo các tài nguyên phần cứng cần thiết để thực hiện đầy đủ chức năng trong phạm vi yêu cầu đã đặt ra Các yếu tố chính ảnh hưởng đến hiệu quả gồm khả năng xử lý của máy tính (được đo bằng MIPS hoặc MHz), khả năng lưu trữ dữ liệu (dung lượng bộ nhớ, đĩa cứng trong MB, GB, TB) và khả năng truyền dữ liệu (đo bằng MBPS, GBPS) Ngoài ra, yêu cầu về tính hiệu quả còn bao gồm mức tối đa tài nguyên phần cứng được sử dụng trong hệ thống và thời gian sạc pin trên các thiết bị di động hoặc máy tính xách tay để đảm bảo hoạt động liên tục.
Tính toàn vẹn trong hệ thống phần mềm là yếu tố rất quan trọng để đảm bảo an ninh và bảo mật dữ liệu Các yêu cầu về tính toàn vẹn giúp ngăn chặn truy cập trái phép, phân biệt rõ ràng giữa nhân viên chỉ có quyền xem thông tin và những nhóm hạn chế được phép thêm hoặc thay đổi dữ liệu Việc đảm bảo tính toàn vẹn dữ liệu không chỉ giúp bảo vệ hệ thống khỏi các mối đe dọa từ bên ngoài mà còn duy trì tính chính xác và độ tin cậy của thông tin trong tổ chức.
Yêu cầu về khả năng sử dụng là yếu tố quan trọng xác định phạm vi tài nguyên nhân lực cần thiết để đào tạo nhân viên mới và vận hành hiệu quả hệ thống phần mềm Đảm bảo nhân viên có đầy đủ kỹ năng sử dụng sẽ giúp tối ưu hóa quá trình triển khai và duy trì hệ thống, nâng cao hiệu suất công việc.
(2) Các yếu tố về rà soát sản phẩm : bảo trì được, linh động và kiểm tra được :
Khả năng bảo trì của phần mềm là yếu tố quan trọng, yêu cầu người dùng và nhân viên bảo trì nỗ lực xác định nguyên nhân lỗi, sửa chữa và xác nhận thành công quá trình sửa lỗi Các yêu cầu này liên quan đến cấu trúc mô-đun của phần mềm, tài liệu nội bộ và hướng dẫn sử dụng dành cho lập trình viên, nhằm đảm bảo phần mềm dễ dàng bảo trì và cập nhật.
Tính linh động là yếu tố quan trọng, bao gồm khả năng và nguồn lực cần thiết để hỗ trợ các hoạt động bảo trì phần mềm Điều này đảm bảo việc thích nghi với các gói phần mềm, khách hàng trong cùng ngành, các mức độ hoạt động khác nhau và đa dạng sản phẩm Yếu tố này cũng thúc đẩy hoạt động bảo trì hoàn hảo thông qua việc thay đổi, bổ sung chức năng để nâng cao dịch vụ và đáp ứng các biến đổi của môi trường thương mại và kỹ thuật của công ty.
Khả năng kiểm tra hệ thống là yêu cầu quan trọng trong việc đảm bảo hoạt động hiệu quả của các hệ thống thông tin, bao gồm các tính năng giúp người kiểm thử dễ dàng thực hiện công việc như đưa ra kết quả trung gian Các tiêu chuẩn kiểm tra tự động trước khi triển khai giúp xác định xem tất cả các thành phần của phần mềm có hoạt động tốt không, đồng thời cung cấp báo cáo lỗi rõ ràng Ngoài ra, việc kiểm tra dự đoán tự động còn hỗ trợ kỹ thuật viên bảo trì phát hiện nguyên nhân gây lỗi phần mềm một cách nhanh chóng và chính xác, nâng cao độ tin cậy của hệ thống thông tin.
(3) Các yếu tố về chuyển giao sản phẩm : tính lưu động (khả năng thích nghi với môi trường), khả năng tái sử dụng và khả năng cộng tác được :
Tính lưu động của hệ thống phần mềm đề cập đến khả năng thích nghi linh hoạt với nhiều môi trường khác nhau, bao gồm các loại phần cứng và hệ điều hành khác nhau Yêu cầu này đảm bảo phần mềm có thể hoạt động một cách độc lập hoặc cùng lúc trong các tình huống đa dạng, giúp nâng cao tính linh hoạt và khả năngvận hành của hệ thống.
Khả năng tái sử dụng phần mềm đóng vai trò quan trọng trong phát triển phần mềm hiện đại, cho phép sử dụng các module đã được thiết kế cho dự án này trong các dự án mới Điều này giúp tiết kiệm tài nguyên phát triển, rút ngắn thời gian triển khai và nâng cao chất lượng sản phẩm Chất lượng của các module cao hơn nhờ vào quá trình phát hiện lỗi qua các hoạt động đảm bảo chất lượng trong quá trình phát triển ban đầu, cũng như từ phản hồi của người dùng trong các lần tái sử dụng trước Các tiêu chuẩn về tái sử dụng phần mềm đã trở thành một phần không thể thiếu trong các tiêu chuẩn công nghiệp phần mềm (IEEE, 1999).
Khả năng cộng tác là yếu tố quan trọng để đảm bảo các giao diện phần mềm hoạt động hiệu quả với các hệ thống khác Các yêu cầu về khả năng cộng tác thường xác định rõ tên của phần mềm và các giao diện bắt buộc, cũng như các cấu trúc đầu ra được chấp nhận theo tiêu chuẩn của ngành hoặc lĩnh vực ứng dụng Việc này giúp tăng tính tương thích và tích hợp dễ dàng giữa các phần mềm khác nhau, nâng cao hiệu quả vận hành trong các hệ thống phần mềm phức tạp.
TÍCH HỢP CÁC HOẠT ĐỘNG ĐẢM BẢO CHẤT LƯỢNG PHẦN MỀM VÀO VÒNG ĐỜI PHÁT TRIỂN PHẦN MỀM
Các phương pháp phát triển phần mềm
- Mô hình vòng đời phát triển phần mềm (SDLC)
Mô hình vòng đời phát triển phần mềm (SDLC) là một mô hình truyền thống vẫn còn ứng dụng hiệu quả, cung cấp mô tả toàn diện về quy trình phát triển phần mềm Nó xác định các khối chính cần xây dựng trong toàn bộ quá trình, được trình bày như một chuỗi tuyến tính Trong giai đoạn đầu của quá trình, các tài liệu thiết kế sản phẩm được chuẩn bị kỹ lưỡng, còn việc đánh giá phiên bản đầu của phần mềm thường chỉ xảy ra ở giai đoạn cuối Ngoài ra, mô hình SDLC còn đóng vai trò như một khung để biểu diễn các mô hình phát triển phần mềm khác nhau.
Thể hiện phổ biến nhất của SDLC là mô hình waterfall (thác nước) Mô hình này được minh họa trong hình dưới đây:
Hình 2-1: Mô hình vòng đời phát triển phần mềm Thác nước
Mô hình gồm có 7 pha: xác định yêu cầu, phân tích, thiết kế, coding, kiểm thử hệ thống, cài đặt và chuyển giao, vận hàng và bảo trì
Pha xác định yêu cầu là bước quan trọng nhằm xác định các chức năng chính của hệ thống cần xây dựng, trong đó khách hàng phải đưa ra và xác định rõ các quyết định của họ Trong nhiều trường hợp, hệ thống phần mềm là một phần của hệ thống lớn hơn, vì vậy việc mở rộng thông tin về các phần khác của hệ thống giúp thiết lập sự hợp tác hiệu quả giữa đội dự án và các giao diện thành phần phát triển Điều này đảm bảo rằng hệ thống tích hợp đầy đủ và đáp ứng đúng nhu cầu của khách hàng.
Phân tích: Nỗ lực chính ở đây là phân tích sự ẩn ý của những yêu cầuthành mô hình khởi tạo của hệ thống phần mềm
Trong giai đoạn thiết kế, việc định nghĩa chi tiết về đầu vào, đầu ra và các thủ tục xử lý là rất quan trọng để đảm bảo hệ thống hoạt động hiệu quả Giai đoạn này cũng bao gồm xác định cấu trúc dữ liệu, thiết kế cơ sở dữ liệu và cấu trúc phần mềm phù hợp Việc lên kế hoạch kỹ lưỡng trong bước thiết kế giúp tạo nền tảng vững chắc cho quá trình phát triển hệ thống, đảm bảo tính khả thi và khả năng mở rộng trong tương lai.
Trong giai đoạn coding, toàn bộ thiết kế phần mềm được chuyển đổi thành mã nguồn thực thi, đảm bảo chất lượng phần mềm thông qua các hoạt động kiểm tra như inspection, kiểm thử đơn vị (unit test) và kiểm thử tích hợp.
Test hệ thống được thực hiện sau khi hoàn thành phần coding nhằm phát hiện và sửa lỗi phần mềm để đạt tiêu chuẩn chất lượng cao nhất Quá trình kiểm thử này do các nhà phát triển thực hiện trước khi bàn giao cho khách hàng, giúp đảm bảo phần mềm đáp ứng các yêu cầu đề ra Trong nhiều trường hợp, khách hàng tham gia vào quá trình test chấp nhận sản phẩm để xác nhận rằng phần mềm hoạt động đúng như cam kết, đồng thời phát hiện các lỗi hoặc phản ứng bất ngờ có thể xảy ra Việc khách hàng tham gia kiểm thử hệ thống giúp tiết kiệm thời gian và tài nguyên, tạo điều kiện cho quá trình kiểm tra diễn ra hiệu quả hơn và đảm bảo sự hài lòng từ phía khách hàng.
Sau khi hệ thống phần mềm được phê duyệt, nó sẽ được cài đặt như một phần của hệ thống thông tin, đóng vai trò là một thành phần mở rộng quan trọng Trong trường hợp hệ thống mới thay thế hệ thống cũ, quy trình chuyển giao cần được thực hiện cẩn thận để đảm bảo hoạt động của tổ chức không bị gián đoạn trong suốt quá trình chuyển đổi.
Vận hành phần mềm bắt đầu sau khi cài đặt và chuyển giao đã hoàn tất, và trong quá trình vận hành kéo dài ít nhất là vài năm hoặc cho đến khi có phần mềm mới thay thế Việc bảo trì phần mềm là cần thiết để đảm bảo hoạt động liên tục và hiệu quả, gồm có ba kiểu dịch vụ chính: thích ứng, nhằm sử dụng các đặc trưng của phần mềm để đáp ứng các yêu cầu mới; hoàn thiện, nhằm thêm các tính năng mới để nâng cao hiệu năng của phần mềm; và sửa lỗi, để khắc phục các lỗi phần mềm được người dùng phát hiện trong quá trình vận hành.
Số lượng các pha trong vòng sống phát triển phần mềm (SDLC) thay đổi tùy thuộc vào đặc trưng của từng dự án Trong các dự án phức tạp và mô hình phần mềm cỡ lớn, một số pha có thể được chia nhỏ, dẫn đến số lượng pha lên đến tám, chín hoặc nhiều hơn Ngược lại, trong các dự án nhỏ, các pha có thể được gộp lại, giảm số lượng xuống còn năm, bốn hoặc thậm chí chỉ còn ba pha Ở cuối mỗi pha, kết quả đều được xem xét và đánh giá bởi các nhà phát triển, đôi khi có sự tham gia của khách hàng, nhằm đảm bảo chất lượng và phù hợp với yêu cầu dự án Các kết quả từ quá trình xem xét có thể gồm những điều chỉnh cần thiết, phản hồi hoặc xác nhận để tiếp tục tiến trình phát triển phần mềm.
• Sự phê chuẩn của các đầu ra ở pha đó và quy trình của pha tiếp theo
Các yêu cầu chỉnh sửa hoặc thay đổi phần cuối cùng của dự án có thể thực hiện và, trong trường hợp cần thiết, các pha gần nhất cũng có thể được điều chỉnh để đảm bảo tính chắc chắn Đường kết nối giữa các hình hộp chữ nhật thể hiện khả năng xuất hiện kết quả khác nhau, vì vậy quá trình thực hiện thường theo kiểu tuyến tính Tuy nhiên, mô hình nhấn mạnh hoạt động phát triển trực tiếp mà không đề cập đến sự tham gia của khách hàng trong quá trình phát triển dự án.
Mô hình Waterfall được đề xuất bởi Royce vào năm 1970 và sau đó được phát triển trong mô hình chung của Boehm năm 1981, trở thành nền tảng cho nhiều tiêu chuẩn đảm bảo chất lượng phần mềm như IEEE 1012 và IEEE 12207.
Mô hình bản mẫu dựa trên sự thay thế của một hoặc nhiều pha trong mô hình
Quy trình SDLC là một phương pháp đánh giá, trong đó các bản mẫu phần mềm được sử dụng để giao tiếp giữa nhà phát triển, người dùng cuối và khách hàng Các bản mẫu này giúp người sử dụng đánh giá và phản hồi, từ đó nhà phát triển phát triển các phiên bản nâng cao của phần mềm Quá trình này diễn ra liên tục cho đến khi dự án phần mềm hoàn chỉnh hoặc đạt các yêu cầu đề ra Khi đạt được mục tiêu, phần còn lại của quy trình phát triển có thể chuyển sang các phương pháp khác, như mô hình SDLC truyền thống, để hoàn thiện sản phẩm cuối cùng.
Hình 2-2: Mô hình Phát triển phần mềm Bản mẫu nhanh
Mô hình xoắn ốc cung cấp phương pháp luận nhằm đảm bảo hiệu quả của từng pha trong quy trình SDLC truyền thống Mô hình này dựa trên quá trình lặp lại, tích hợp các yêu cầu thay đổi của khách hàng, phân tích và xử lý rủi ro, cùng với các hoạt động kỹ thuật và lập kế hoạch phát triển phần mềm Một trong những điểm nổi bật của mô hình này là yêu cầu hoàn thiện ở mỗi giai đoạn của dự án trong chu trình SDLC, giúp nâng cao hiệu quả và linh hoạt trong quản lý dự án phần mềm.
Hình 2-3: Mô hình phát triển phần mềm Xoắn ốc
Mô hình hướng đối tượng tích hợp chặt chẽ việc tái sử dụng phần mềm lớn thông qua việc kết hợp các mô đun có thể sử dụng lại thành các hệ thống phần mềm mới Khi không có mô đun phần mềm khả dụng theo thuật ngữ đối tượng hoặc thành phần, nhà phát triển có thể áp dụng quy trình bản mẫu hoặc quy trình SDLC để phát triển hệ thống mới một cách hiệu quả.
Các hoạt động đảm bảo chất lượng phần mềm
2.2.1 Đảm bảo chất lượng hợp đồng
Một hợp đồng tồi thường gây khó khăn và không chấp nhận được, đặc biệt từ góc nhìn của SQA, vì nó thường phản ánh các yêu cầu không rõ ràng và lập kế hoạch cũng như ngân sách phi thực tế, dẫn đến chất lượng phần mềm kém Do đó, thực hiện chương trình SQA nhằm rà soát kỹ lưỡng các đề xuất ban đầu và bản dự thảo hợp đồng là rất cần thiết để nâng cao chất lượng sản phẩm Hoạt động “rà soát hợp đồng” giúp cải thiện ngân sách, thời gian biểu, đồng thời xác định sớm các rủi ro tiềm năng trong mục tiêu ban đầu và trong các đề xuất hợp đồng, từ đó đảm bảo các đề nghị và hợp đồng sau này khả thi và hiệu quả hơn.
Có khá nhiều tình huống có thể giúp một công ty phần mềm (“nhà cung cấp”) ký hợp đồng với một khách hàng Phổ biến nhất là:
• Tham gia trong một cuộc đấu thầu
• Đưa ra bản phác thảo dựa trên yêu cầu đề xuất (RFP-Request For Proposal) của khách hàng
• Nhận một đặt hàng từ một khách hàng của công ty
• Nhận một yêu cầu từ bên trong hoặc từ phòng ban khác trong một tổ chức
Rà soát hợp đồng là một phần quan trọng của quy trình SQA, giúp đánh giá các bản dự thảo tài liệu đề xuất và hợp đồng một cách chính xác và hiệu quả Việc rà soát còn đảm bảo giám sát các hợp đồng đã thực hiện với các đối tác dự án tiềm năng và nhà thầu phụ, nâng cao sự minh bạch và quản lý rủi ro Quy trình rà soát hợp đồng thường được chia thành hai giai đoạn chính: đánh giá ban đầu và kiểm tra cuối cùng, nhằm đảm bảo mọi điều khoản đều phù hợp với yêu cầu dự án và tiêu chuẩn chất lượng.
Trong Giai đoạn 1, việc rà soát bản dự thảo đề xuất là bước quan trọng để đảm bảo tính chính xác và đầy đủ trước khi gửi tới khách hàng tiềm năng Quá trình này bao gồm kiểm tra kỹ lưỡng bản dự thảo cuối cùng cùng các tài liệu liên quan như yêu cầu của khách hàng, các yêu cầu bổ sung, diễn giải các yêu cầu, ước lượng chi phí và nguồn lực cần thiết Ngoài ra, cần xem xét các hợp đồng hiện tại hoặc bản dự thảo hợp đồng của nhà cung cấp với đối tác và nhà thầu phụ để đảm bảo sự phù hợp và chính xác của đề xuất.
Giai đoạn 2 trong quy trình ký kết hợp đồng là rà soát lại bản dự thảo hợp đồng trước khi ký, đảm bảo rằng tất cả các điều khoản phù hợp với đề xuất và hiểu biết đã đạt được trong quá trình thương thảo Trong giai đoạn này, việc kiểm tra kỹ lưỡng bản dự thảo hợp đồng giúp phát hiện và chỉnh sửa những điểm cần thiết, bao gồm các thay đổi đã thống nhất để đảm bảo quyền lợi và nghĩa vụ của các bên đều rõ ràng, chính xác Việc rà soát hợp đồng kỹ lưỡng trước khi ký kết là bước quan trọng để tránh những tranh chấp không mong muốn sau này.
Quá trình rà soát bắt đầu sau khi các tài liệu dự thảo liên quan đã hoàn thành, nhằm đảm bảo tính chính xác và phù hợp của nội dung Những cá nhân thực hiện rà soát cần xem xét kỹ lưỡng bản dự thảo, bao gồm toàn diện các đối tượng liên quan để đảm bảo không bỏ sót các vấn đề quan trọng Việc sử dụng danh sách kiểm tra là công cụ hữu ích giúp đảm bảo quá trình rà soát diễn ra đầy đủ và có hệ thống, tăng cường hiệu quả kiểm tra các yếu tố cần thiết.
Sau khi hoàn thành giai đoạn rà soát, các thay đổi, bổ sung và hiệu chỉnh cần được đội đề xuất thông báo (sau khi rà soát bản dự thảo đề xuất), đồng thời ban phụ trách về luật pháp cũng sẽ kiểm tra và phê duyệt các chỉnh sửa (sau khi rà soát lại bản dự thảo hợp đồng).
2.2.2 Đảm bảo chất lượng đặc tả
2.2.2.1 Chất lượng đặc tả Đặc tả không có các hoạt động trước nó, và tất cả các hoạt động khác đều theo sau đặc tả Vì vậy, nếu đặc tả không tốt thì phân tích, thiết kế cũng sẽ không tốt, và dẫn tới phát triển, bảo trì của 1 phần mềm kém hơn, hoặc thậm chí một phần mềm lỗi, và công sức bỏ ra để đảm bảo chất lượng thành lãng phí Vì vậy, điều tối quan trọng là đặc tả phải đầy đủ và được định nghĩa tốt Đặc tả thường gồm 6 nội dung sau:
• Chức năng: đặc tả các chức năng nào sẽ được phát triển
Hệ thống cần có khả năng chịu tải phù hợp, ví dụ như có thể phục vụ cùng lúc 100 người thao tác, đảm bảo hiệu suất ổn định và đáng tin cậy Ngoài ra, xác định rõ mục đích sử dụng của sản phẩm giúp đảm bảo các yêu cầu kỹ thuật và chức năng phù hợp với nhu cầu của người dùng Việc đặc tả rõ ràng về khả năng chịu tải và mục đích sử dụng đóng vai trò quan trọng trong việc thiết kế và lựa chọn giải pháp phù hợp, tối ưu hóa hiệu quả vận hành và đảm bảo sự hài lòng của khách hàng.
(c)Tính tin cậy: đặc tả thời gian mà sản phẩm có thể hoạt động tốt trước khi cần bảo trì và phù hợp với yêu cầu của người dùng
Tính an toàn của sản phẩm được đặc tả qua ngưỡng an toàn cho con người và các đặc tính khi sử dụng phần mềm, đảm bảo người dùng không gặp phải rủi ro Đồng thời, tính bảo mật được xác định bằng cách liệt kê các mối đe dọa mà sản phẩm cần chuẩn bị để đối phó, nhằm bảo vệ dữ liệu và hệ thống khỏi các nguy cơ tiềm ẩn.
Để đảm bảo đặc tả đầy đủ và chính xác, người phân tích nghiệp vụ hoặc người phân tích hệ thống cần đảm nhận nhiệm vụ này, đặc biệt là trong lĩnh vực đặc tả chức năng Trong khi đó, đối với đặc tả phi chức năng, cần xây dựng các chuẩn nội bộ hoặc áp dụng các tiêu chuẩn chuyên nghiệp để đảm bảo chất lượng và tính chính xác của tài liệu.
2.2.2.2 Đảm bảo chất lượng đặc tả
Trong công nghiệp phần mềm, đặc tả được xem như là đặc tả của người dùng, phản ánh rõ các yêu cầu mà người dùng cuối mong muốn từ phần mềm Các tình huống sau đây có thể được sử dụng để thu thập đặc tả người dùng, giúp đảm bảo rằng phần mềm đáp ứng đúng nhu cầu và mong đợi của người dùng cuối một cách chính xác và hiệu quả.
- Người phân tích nghiệp vụ tìm hiểu, viết báo cáo, xây dựng đặc tả Họ cần:
• Gặp tất cả người dùng cuối để lấy các yêu cầu và lưu ý của họ
• Gặp tất cả người đứng đầu các bộ phận để lấy yêu cầu và lưu ý của họ
• Gặp người quản lý để lấy yêu cầu và lưu ý của họ
• Tổng hợp các yêu cầu và trình bày để người dùng cuối, người đứng đầu các bộ phận và người quản lý phản hồi, nhận xét
• Chỉnh sửa theo phản hồi, nhận xét và xây dựng bản đặc tả chuẩn
- Có sẵn một bản yêu cầu người dùng như một phần của bản đề xuất
- Yêu cầu tham khảo một sản phẩm tương tự và cung cấp các tuỳ chỉnh riêng cho khách hàng
Khi đặc tả đã hoàn thiện, bước đảm bảo chất lượng sẽ bắt đầu thực hiện để xác minh tính đầy đủ và chính xác của các yêu cầu chức năng cũng như phi chức năng Nhiệm vụ chính của hoạt động đảm bảo chất lượng trong giai đoạn này là kiểm tra, đánh giá để đảm bảo các đặc tả phản ánh đúng các tiêu chí đề ra Quá trình này giúp đảm bảo rằng các đặc tả đã sẵn sàng để tiếp tục bước phát triển, giảm thiểu rủi ro và đảm bảo chất lượng dự án.
Các công cụ có thể sử dụng để đảm bảo chất lượng cho đặc tả là:
- Tài liệu quy trình: chi tiết phương pháp để lấy, phát triển, phân tích và tổng hợp đặc tả
- Các chuẩn (standard), hướng dẫn (guideline), các biểu mẫu (template): xác định tập tối thiểu các đặc tả cần phải xây dựng
- Danh sách kiểm tra (checklist): giúp phân tích để đảm bảo tính đầy đủ của đặc tả
Các công cụ này giúp nhà phân tích xây dựng đặc tả rõ ràng và đầy đủ, đảm bảo chuẩn bị tốt cho các bước tiếp theo như phân tích và thiết kế Việc sử dụng chúng còn giúp đảm bảo chất lượng của đặc tả, từ đó nâng cao hiệu quả quá trình phát triển phần mềm Chuẩn bị đặc tả kỹ lưỡng là bước quan trọng để đảm bảo dự án thành công, giảm thiểu sai sót và tăng tính chính xác trong quá trình thực hiện.
Các công cụ đảm bảo chất lượng đặc tả bao gồm quá trình rà soát chính thức và rà soát ngang hàng, giúp nâng cao độ chính xác và độ tin cậy của tài liệu Những phương pháp rà soát này sẽ được trình bày chi tiết tại Chương 3, cung cấp hướng dẫn rõ ràng để kiểm tra chất lượng đặc tả một cách hiệu quả.
2.2.3 Đảm bảo chất lượng phân tích, thiết kế
2.2.3.1 Chất lượng phân tích, thiết kế
Phân tích và thiết kế là bước quan trọng để đảm bảo chất lượng sản phẩm phần mềm, tránh lỗi ngay cả khi đặc tả được thực hiện tốt Phân tích bao gồm xác định kiến trúc, chức năng và cách tiếp cận phù hợp với các yêu cầu về tính linh hoạt, tính di động và khả năng bảo trì của hệ thống Trong khi đó, thiết kế tập trung vào việc phát triển cơ sở dữ liệu, giao diện người dùng, báo cáo và các thành phần liên quan khác Quá trình phân tích và thiết kế đúng quy trình giúp xây dựng phần mềm hiệu quả, dễ bảo trì và đáp ứng đầy đủ yêu cầu của khách hàng.
4 Thiết kế cơ sở dữ liệu
7 Thiết kế giao diện người dùng
14.Tính hiệu quả và tính đồng thời
CÁC HOẠT ĐỘNG RÀ SOÁT
Mục tiêu của rà soát
3.1.1 Định nghĩa Định nghĩa của IEEE (1990), quá trình rà soát là:
Quá trình hoặc cuộc họp trình bày sản phẩm công việc hoặc các tập hợp sản phẩm tới toàn bộ các bên liên quan như giám đốc, người dùng, khách hàng để lấy ý kiến đóng góp và phê duyệt dự án Quá trình này đảm bảo sự phối hợp và xác nhận cuối cùng của các bên để đảm bảo chất lượng cũng như phù hợp với yêu cầu dự án Đây là bước quan trọng trong quy trình quản lý dự án nhằm đảm bảo mọi sản phẩm đều đáp ứng tiêu chuẩn và mong đợi của các bên liên quan.
Một số phương pháp dùng để xem xét lại tài liệu:
- Xem xét lại thiết kế hình thức (Formal design reviews)
- Xem xét lại ngang hàng (Peer reviews)
Mục đích được chia làm 2 loại: mục đích trực tiếp và gián tiếp
Mục đích trực tiếp của quá trình này là phát hiện lỗi trong phân tích và thiết kế, giúp xác định các rủi ro mới có thể ảnh hưởng đến dự án Nó còn nhằm xác định sự sai lệch so với mẫu, các kiểu thủ tục và quy ước đã đề ra, từ đó đảm bảo tính chính xác và nhất quán của sản phẩm Cuối cùng, quá trình này nhằm phê chuẩn sản phẩm sau khi đã hoàn thiện phân tích hoặc thiết kế, đảm bảo đáp ứng các tiêu chuẩn chất lượng và yêu cầu đề ra.
Mục đích gián tiếp của các cuộc họp không chính thức là để trao đổi kiến thức chuyên môn, giúp các thành viên nâng cao kỹ năng và hiểu biết trong lĩnh vực của mình Đồng thời, những cuộc họp này còn ghi lại các lỗi phân tích và thiết kế, tạo nền tảng cho hoạt động sửa chữa lỗi hiệu quả trong tương lai.
Các hình thức rà soát
Rà soát thiết kế chính thức(DRs-formal Design Reviews) là rà soát duy nhất cần thiết cho việc phê duyệt sản phẩm thiết kế
Việc rà soát thiết kế hình thức là bước quan trọng có thể thực hiện ở bất kỳ giai đoạn phát triển nào khi cần hoàn thiện tài liệu phân tích hoặc thiết kế Quá trình này giúp đảm bảo tính chính xác, nhất quán và phù hợp của tài liệu, từ đó nâng cao chất lượng dự án Rà soát thiết kế hình thức giúp phát hiện và sửa lỗi kịp thời, đảm bảo tiến độ và hiệu quả công việc Thực hiện đều đặn ở các mốc phát triển sẽ góp phần tạo ra sản phẩm cuối cùng hoàn thiện và đáp ứng yêu cầu đề ra.
Ví dụ các review trong quá trình phát triển phần mềm :
• DPR – Development Plan Review : Review kế hoạch phát triển
• SRSR – Software Requirement Specification Review : Review đặc tả yêu cầu phần mềm
• PDR – Preliminary Design Review : Review thiết kế sơ bộ
• DBDR- Detailed Design Review : Review thiết kế chi tiết
• TPR – Test Plan Review : Review kế hoạch kiểm thử
• STPR – Software Test Procedure Review : Review thủ tục kiểm thử phần mềm
• VDR- Version Description Review : Review mô tả phiên bản
• OMR- Operator Manual Review : Review vận hành thủ công
• SMR- Support Manual Review :Review trợ giúp thủ công
• TRR- Test Readiness Review : Review sự sẵn sàng kiểm thử
• PRR- Product Release Review : Review bản phát hành sản phẩm
• IPR-Installation Plan Review : Review kế hoạch cài đặt
Các nhân tố ảnh hưởng tới DRs
• Các hoạt động sau DR được đề xuất
Những người tham gia rà soát thiết kế
Gồm có Review leader và review team
• Có kiến thức và kinh nghiệm trong việc phát triển kiểu dự án được review
• Có thâm niên ở mức độ bằng với hoặc cao hơn của project leader
• Có mối quan hệ tốt với project leader và đội dự an
• Có vị trí bên ngoài đội dự án
• Phần lớn không thuộc đội dự án
• Đa dạng về kinh nghiệm và phương pháp
Sự chuẩn bị cho một phiên làm việc DR Được hoàn thành bởi 3 thành viên: review leader, review team và development team
Chuẩn bị của Review leader
• Bổ nhiệm các thành viên nhóm
• Lập lịch các phiên review
• Phân chia tài liệu thiết kế cho các thành viên của nhóm
Chuẩn bị của Review team
• Xem lại tài liệu thiết kế
Chuẩn bị của Development team
• Trình diễn ngắn tài liệu thiết kế
• Checklist các công việc review
Một cuộc họp phiên DR thông thường gồm có :
1 Trình diễn ngắn gọn về tài liệu thiết kế
2 Các bình luận của các thành viên review team
3 Kiểm tra và xác nhận thảo luận mỗi bình luận
4 Các quyết định về tài liệu thiết kế để xác định tiến trình dự án Các quyết định có thể có 3 loại :
Các hoạt động hậu review
• Review leader thực hiện sau phiên review
Trong cuộc họp, chúng tôi đã tổng kết các thảo luận review dự án để đánh giá tiến độ và hiệu quả Quyết định về việc tiếp tục dự án cũng đã được thống nhất, dựa trên các phân tích và kết quả đạt được Đồng thời, danh sách các hoạt động cần thiết phải thực hiện trong giai đoạn tiếp theo đã được xác định rõ ràng Các thành viên chịu trách nhiệm theo sát việc hiệu chỉnh và đảm bảo các nhiệm vụ được thực hiện đúng tiến độ và đạt chất lượng cao.
• Tiến trình theo dõi o Review leader thực hiện o Chắc rằng việc hiệu chỉnh được thực hiện đúng đắn Việc theo dõi cần được ghi lại
Mục đích chính của peer review là xác định lỗi và độ lệch dựa vào các chuẩn
Có hai phương pháp peer reviews:
• kiểm tra từng bước (walkthrough)
Walkthrough phát hiện sai sót và ghi chú lên tài liệu
Inspection phát hiện sai sót và kết hợp với nỗ lực để cải tiến
Những người tham gia vào peer reviews
Một đội peer review tối ưu 3-5 người tham gia
Tất cả những người tham gia nên là những người cùng địa vị của nhà thiết kế hệ thống phần mềm
Một đội peer review đề cử bao gồm:
• Một người thực thi (author)
• Các chuyên gia đặc biệt (specialized professionals)
Phân công trách nhiệm trong đội (team assignments)
Hai trong số các thành viên sẽ là:
• một người dẫn chương trình
• một người viết tài liệu trong cuộc thảo luận
Chuẩn bị cho phiên peer review
Người lãnh đạo chịu trách nhiệm xác định các đoạn trong tài liệu thiết kế cần được xem xét và đánh giá Họ cũng lựa chọn thành viên nhóm phù hợp để tham gia vào quá trình review nhằm đảm bảo chất lượng tài liệu Bên cạnh đó, lãnh đạo lập lịch các phiên review để tổ chức công việc một cách khoa học và hiệu quả Cuối cùng, tài liệu thiết kế cần được phân phối cho tất cả các thành viên trong đội trước khi diễn ra các phiên review để đảm bảo mọi người đều có thể chuẩn bị kỹ lưỡng.
The peer review team faces meticulous inspection requirements, which involve detailed reading and annotating the content In contrast, the walkthrough process is simpler, focusing on reviewing specific sections of the material During inspection, participants are expected to carefully read and note their comments, while walkthroughs involve straightforward reading of selected segments for review This distinction highlights the thoroughness of inspections compared to the more basic approach of walkthroughs.
Trong quá trình trình bày, nhà thuyết trình đọc một đoạn tài liệu quan trọng và có thể bổ sung thông tin cần thiết để làm rõ nội dung Những người liên quan có thể đưa ra chú thích hoặc phản hồi các ý kiến trong tài liệu, giúp tăng tính tương tác và làm rõ hơn nội dung trình bày Việc này không chỉ nâng cao chất lượng bài thuyết trình mà còn giúp khán giả dễ hiểu và ghi nhớ thông tin hơn.
Trong quá trình walkthrough, tác giả bắt đầu bằng phần trình bày ngắn gọn về dự án hoặc tổng quan về các đoạn thiết kế sẽ được review, giúp người tham gia hiểu rõ mục tiêu Tiếp theo, cần ghi lại chính xác vị trí, mô tả, kiểu dáng và đặc điểm của từng lỗi được chấp nhận, bao gồm những sai sót, thiếu sót hoặc phần cần thêm vào để đảm bảo quy trình kiểm tra rõ ràng và hiệu quả.
Quy tắc thời gian: phiên không nên vượt quá 2 giờ, hoặc lập lịch không nhiều hơn 2 ngày
Tài liệu sau mỗi phiên review: o Báo cáo những phát hiện trong phiên inspection o Báo cáo tóm tắt của phiên inspection
Các hoạt động sau peer review (post-peer review activities)
Inspection: o Nhắc nhở, sửa chữa hiệu quả, làm lại tất cả các lỗi o Chuyển giao các bản báo cáo inspection tới CAB để phân tích
Hiệu quả của peer review (the efficency of peer reviews)
Các chỉ số đo lường hiệu quả của quá trình đánh giá chéo (peer review) bao gồm số giờ trung bình để phát hiện một lỗi, mật độ phát hiện thiếu sót (số thiếu sót trung bình trên mỗi trang tài liệu thiết kế), hiệu năng nội bộ của peer review và tỷ lệ phạm vi đánh giá (peer review coverage), thể hiện tỷ lệ phần trăm tài liệu và mã nguồn đã trải qua quá trình kiểm tra Những chỉ số này giúp đánh giá mức độ hiệu quả và phạm vi của quy trình peer review trong phát hiện và sửa lỗi sớm, từ đó nâng cao chất lượng sản phẩm phần mềm.
3.2.3 Ý kiến chuyên gia Ý kiến của chuyên ra rất hữu ích trong những trường hợp sau: o Thiếu sự hiểu biết đầy đủ về lĩnh vực nào đó o Tạm thời thiếu những người chuyên nghiệp để tham gia vào đội xem xét lại o Các thành viên chuyên nghiệp cao cấp trong tổ chức không thống nhất được với nhau o Trong các tổ chức nhỏ số lượng ứng viên phù hợp cho đội xem xét lại là không đủ
3.2.4 So sánh rà soát chính thức và rà soát ngang hàng Để rõ hơn những đặc điểm của các phương pháp rà soát có thể tham khảo bảng so sánh giữa ba phương pháp rà soát sau đây:
Thuộc tính Formal design reviews Inspections Walkthroughs
Mục đích chính trực tiếp
Xác định rủi ro mới
Phê chuẩn tài liệu thiết kế
Xác định sự sai lệch so với tiêu chuẩn
Mục đích chính gián tiếp
Trao đổi kiến thức Trao đổi kiến thức
Hỗ trợ hoạt động sửa chữa
Lãnh đạo việc xem xét lại
Người đứng đầu kỹ nghệ phần mềm hoặc là thành viên cao cấp
Người điều hành chỉ đạo (ngang hàng)
Người tham gia Các thành viên cấp cao và đại diện khách hàng
Sự tham gia của trưởng dự án
Có Có Có, thông thường là khi bắt đầu xem xét lại
Thành viên chuyên gia trong đội
Người thiết kế Lập trình viên
Người giám sát tiêu chuẩn
Quá trình xem xét lại
Họp tổng quan Không Có Có
Sự chuẩn bị của những người tham gia
Có – chuẩn bị kỹ lưỡng
Có – chuẩn bị kỹ lưỡng
Có – chuẩn bị tóm lược
Phiên xem xét lại Có Có Có
Bám sát việc sửa chữa
Cơ sở hạ tầng Đào tạo chính thức cho người tham gia
Sử dụng checklist Không Có Không
Lỗi liên quan đế thu thập dữ liệu
Không yêu cầu hình thức
Yêu cầu hình thức Không yêu cầu hình thức
Tài liệu hóa việc xem xét lại
Báo cáo xem xét lại thiết kế hình thức
Báo cáo đánh giá phiên thanh tra
Báo cáo tổng kết phiên thanh tra
Báo cáo đánh giá phiên walkthrough
Thực hiện hoạt động rà soát trong dự án
- Những mục đích của công việc rà soát bản dự thảo đề xuất
Mục đích của việc rà soát bản dự thảo đề xuất là để đảm bảo rằng những hoạt động sau được thực hiện một cách thỏa đáng
1) Những yêu cầu của khách hàng đã được giải thích chi tiết và có chú giải
Các tài liệu yêu cầu đề xuất (RFP) và các tài liệu công nghệ tương tự thường thiếu rõ ràng, gây ra sự mơ hồ về mục tiêu dự án Do đó, cần bổ sung thêm chi tiết từ khách hàng để làm rõ yêu cầu Việc ghi lại các giải thích về yêu cầu chưa rõ ràng và các cập nhật liên quan vào một tài liệu riêng đã được sự chấp thuận của cả khách hàng và công ty phần mềm, giúp đảm bảo sự thống nhất và rõ ràng trong quá trình triển khai dự án.
2) Lựa chọn những phương pháp thực hiện dự án đã được kiểm tra
Thông thường, những lựa chọn phù hợp và có triển vọng đều đã được đội đề xuất xem xét kỹ lưỡng Điều kiện quan trọng bao gồm việc hoàn thành thay thế thông qua tái sử dụng phần mềm, cũng như thiết lập các mối quan hệ đối tác hoặc hợp đồng lại với các công ty có chuyên môn phù hợp hoặc nhân viên có chuyên môn đảm bảo tuân thủ các điều khoản của đề xuất.
3) Những khía cạnh hình thức của mối quan hệ giữa khách hàng và công ti phần mềm phải được ghi rõ Đề xuất nên định nghĩa những thủ tục bao gồm:
• Sự giao tiếp với khách hàng và những kênh giao diện
• Việc chuyển giao dự án và tiêu chuẩn được chấp nhận
• Tiến trình phê chuẩn pha hình thức
• Phương thức tiếp theo khách hàng thiết kế và kiểm tra
• Thủ tục khách hàng thay đổi yêu cầu
4) Xác định những rủi ro khi phát triển
Các rủi ro trong quá trình phát triển dự án bao gồm việc thiếu kiến thức chuyên môn liên quan đến lĩnh vực nghiệp vụ, điều này có thể ảnh hưởng đến chất lượng và hiệu quả của sản phẩm Ngoài ra, việc không nắm vững cách sử dụng các công cụ phát triển yêu cầu cũng tạo ra nguy cơ gây ra lỗi và trì hoãn trong quá trình triển khai Việc xác định và giải quyết các rủi ro này là bước quan trọng để đảm bảo dự án thành công và đạt được mục tiêu đề ra.
5) Ước lượng đầy đủ những tài nguyên và thời gian biểu của dự án
Việc ước lượng tài nguyên là yếu tố quan trọng trong quản lý dự án, bao gồm đội ngũ nhân viên chuyên nghiệp, ngân sách dự án và chi phí cho các nhà thầu phụ Đồng thời, ước lượng thời gian dự án cần phản ánh rõ các yêu cầu về thời gian của tất cả các bên liên quan để đảm bảo tiến độ và hiệu quả công việc.
Trong một số trường hợp, nhà cung cấp cố ý đề xuất mức chi phí thấp nhằm xem xét các yếu tố tiềm năng bán hàng Khi đề xuất dựa trên ước lượng thực tế về thời gian, ngân sách và khả năng chuyên môn, những tổn thất phát sinh được coi là mất mát có thể tính toán chứ không phản ánh thất bại của hợp đồng.
6) Kiểm tra năng lực của công ti đối với dự án
Việc kiểm tra năng lực nên đánh giá khả năng chuyên môn của các thành viên trong đội ngũ, đồng thời xem xét khả năng sẵn sàng để đảm bảo họ phù hợp với yêu cầu công việc Ngoài ra, quá trình này cần xem xét các cơ hội phát triển kỹ năng trong thời gian đã được lên kế hoạch, giúp đội ngũ có thể liên tục nâng cao hiệu quả công việc.
7) Kiểm tra năng lực của khách hàng để đáp ứng những yêu cầu của mình
Việc kiểm tra khả năng tài chính và tổ chức của khách hàng là yếu tố quan trọng để đảm bảo quá trình tuyển dụng, đào tạo nhân sự hiệu quả Ngoài ra, quá trình này còn liên quan đến cài đặt các phần cứng cần thiết và nâng cấp thiết bị liên lạc để đáp ứng yêu cầu dự án.
8) Định nghĩa đối tác và nhà thầu phụ tham gia Điều này bao gồm các vấn đề bảo đảm chất lượng, lịch trình thanh toán, phân phối thu nhập, lợi nhuận của dự án, và hợp tác giữa quản lý dự án và các đội
9) Định nghĩa và bảo vệ quyển sở hữu
Yếu tố này đóng vai trò quan trọng trong việc tái sử dụng phần mềm, bao gồm quyết định về việc thêm gói mới hoặc sử dụng phần mềm đã qua sử dụng trong tương lai Nó cũng liên quan đến việc bảo vệ các file độc quyền chứa dữ liệu quan trọng cho hoạt động hệ thống, đảm bảo các biện pháp an ninh được thực thi hiệu quả để bảo vệ thông tin nhạy cảm.
Mục tiêu của việc rà soát bản dự thảo đề xuất nhằm đảm bảo tính chính xác và hợp lý của các đề xuất, giúp cải thiện nội dung phù hợp với yêu cầu thực tế và tiêu chuẩn kỹ thuật Quá trình này còn nhằm xác định các điểm mạnh và điểm cần chỉnh sửa để nâng cao chất lượng dự thảo, từ đó tăng tính khả thi và hiệu quả của dự án hoặc chính sách đề xuất Ngoài ra, rà soát còn giúp đảm bảo tính nhất quán, tuân thủ các tiêu chí về pháp lý và chiến lược phát triển, góp phần thành công trong việc triển khai dự án một cách suôn sẻ và bền vững.
9 mục tiêu của việc rà soát bản dự thảo đề xuât đảm bảo rằng những hành động sau đây được thực hiện một cách thỏa đáng:
1 Những yêu cầu của khách hàng đã được giải thích chi tiết và có chú giải
2 Lựa chọn những phương pháp thực hiện dự án đã được kiểm tra
3 Những khía cạnh hình thức của mối quan hệ giữa khách hàng và công ti phần mềm phải được ghi rõ
4 Xác định những rủi ro khi phát triển
5 Ước lượng đầy đủ những tài nguyên và thời gian biểu của dự án
6 Kiểm tra năng lực của công ti đối với dự án
7 Kiểm tra năng lực của khách hàng để đáp ứng những yêu cầu của mình
8 Định nghĩa đối tác và nhà thầu phụ tham gia
9 Định nghĩa và bảo vệ quyển sở hữu
- Những mục tiêu của rà soát dự thảo hợp đồng
Những mục tiêu của việc rà soát bản dự thảo hợp đồng để đảm bảo rằng những hoạt động sau đây được thực hiện một cách thỏa đáng:
1) Không có vấn đề chưa rõ ràng nào vẫn còn lại trong dự thảo hợp đồng
2) Tất cả những thỏa thuận đạt được giữa các khách hàng và công ty phải được giải thích đầy đủ và chính xác trong hợp đồng và phụ lục của nó Những hiểu biết này được dùng để giải quyết tất cả các vấn đề chưa rõ ràng và khác biệt giữa khách hàng và công ty mà đã được đưa ra cho đến nay
3) Không có sự thay đổi, bổ sung, hoặc thiếu sót nào không được thảo luận và sự thoả thuận nên được đưa vào dự thảo hợp đồng Việc thay đổi, dù cố ý hay không, có thể dẫn đến sự bổ sung đáng kể và những nhiệm vụ bất ngờ trong một bộ phận của nhà cung cấp
Những mục tiêu của việc rà soát lại dự thảo hợp đồng có thể được tổng kết trong bảng 5.2
Những mục tiêu của việc rà soát dự thảo hợp đồng
Ba mục tiêu của việc rà soát dự thảo hợp đồng nhằm đảm bảo những hoạt động sau đây được thực hiện một cách thỏa đáng:
1) Không có vấn đề chưa rõ ràng nào vẫn còn lại trong dự thảo hợp đồng
2) Mọi thỏa thuận đã đạt được sau khi xem xét những đề xuất phải được chú giải một cách chính xác
3) Không có sự thay đổi, bổ sung, hoặc thiếu sót đưa vào bản dự thảo hợp đồng
3.3.2 Rà soát phân tích thiết kế
Danh mục rà soát thiết kế
Công s ứ c th ự c hi ệ n rà soát (gi ờ công):
Câu h ỏ i Yes No N/A Ghi chú
Kiểm chứng xem các thủ tục rà soát tài liệu có được tuân thủ không bằng cách kiểm tra các tiêu chí dưới đây:
Trang tiêu đề có tên tài liệu, mã phiên bản, ngày phát hành?
Header và footer có ghi rõ tên và phiên bản tài liệu không?
Phần đánh số trang có chỉ rõ tổng số trang của tài liệu không?
Có thể theo dõi được lịch sử không?
Tài li ệ u có g ồ m danh sách các tài li ệ u tham kh ả o không?
Ki ế n trúc h ệ th ố ng có bao g ồ m các lu ồ ng d ữ li ệ u, lu ồ ng đ i ề u khi ể n, các thành ph ầ n cao c ấ p và giao đ i ệ n có đượ c bi ể u di ễ n rõ ràng không?
Các giao di ệ n bên ngoài, bao g ồ m các giao di ệ n ng ườ i dùng có đượ c đị nh ngh ĩ a và ki ể m ch ứ ng không?
Kiến trúc có được phân lớp thích hợp không?
Chiến lược xử lý lỗi có được mô tả và kiểm chứng không?
Các chiến lược vào/ra có được mô tả và kiểm chứng không?
Tất cả các thành phần chính có được mô tả và kiểm chứng không?
Luồng dữ liệu giữa các thành phần có được mô tả không?
Các thuật toán chính có được mô tả và kiểm chứng không?
T ấ t c ả d ữ li ệ u và tài nguyên đượ c chia s ẻ gi ữ a các thành ph ầ n có đượ c mô t ả không?
Có bắt được hết tất cả các trạng thái và sự kiện quan trọng của hệ thống không?
Các cấu trúc dữ liệu chính cần được mô tả rõ ràng và kiểm chứng để đảm bảo tính chính xác và hiệu quả trong việc thực hiện các thủ tục Bên cạnh đó, việc xác định các đầu vào cần thiết và đủ điều kiện để thực hiện các hành động yêu cầu là yếu tố quan trọng, giúp đảm bảo tính hợp lý và khả thi của các quy trình.
Có chiến lược được mô tả và kiểm chứng cho:
Việc xử lý các trạng thái đặc biệt ko? (Vd: kết thúc bất thường, khôi phục lỗi, mất kiểm soát)
Vi ệ c x ử l ý h ỏ ng h ệ th ố ng không? (Vd: k ế t thúc ti ế n trình, khôi ph ụ c h ệ thống)
Việc quản lý bộ nhớ không? Có ước lượng bộ nhớ đã sử dụng không?
Việc quản lý các tài nguyên được chia sẻ không? Các module sử dụng tài nguyên được chia sẻ có được chỉ rõ không? x
Mỗi đơn vị có một định danh duy nhất và tuân theo quy ước về kiểu và đặt tên không? x
Ngôn ngữ lập trình và các công nghệ được đề xuất có tương thích không? x
Thiết kế phù hợp cho từng đơn vị chứa, bao gồm các thành phần như cấu trúc tĩnh, định nghĩa dữ liệu, luồng dữ liệu, kiểm soát luồng và trạng thái, là điều cần thiết để đảm bảo hệ thống hoạt động hiệu quả và tối ưu Việc này giúp tối ưu hoá quá trình xử lý dữ liệu, nâng cao khả năng mở rộng và dễ dàng bảo trì hệ thống trong tương lai Đảm bảo các thành phần này được xây dựng rõ ràng, thống nhất sẽ tạo nền tảng vững chắc cho các ứng dụng phần mềm, đồng thời phù hợp với các tiêu chuẩn SEO và nâng cao khả năng tìm kiếm trên các công cụ tìm kiếm.
Toàn bộ hàm và mục đích của mỗi đơn vị có được mô tả không? x
Các lời gọi, sự kiện và thông điệp giữa các đơn vị có được ghi trong tài liệu không? x
Thiết kế có phản ánh môi trường hoạt động thực tế không? Phần cứng?
Đảm bảo chất lượng của các thành phần bảo trì phần mềm
Giai đoạn hoạt động của vòng đời phần mềm thường kéo dài từ 5 đến 10 năm, thậm chí có những trường hợp hoạt động trên 15 năm Điều giúp phần mềm duy trì tuổi thọ cao và hài lòng nhóm người dùng là yếu tố chính - đó chính là chất lượng bảo trì Khả năng bảo trì phần mềm quyết định thành công và thời gian dài hạn của nó, như được nhấn mạnh trong các tiêu chuẩn ISO 9000–3, ISO/IEC 2001, IEEE 1998, cũng như các nghiên cứu của Oskarsson và Glass. -**Sponsor**Sounds like you're looking to refine your article and make sure it's SEO-friendly! It can be tough to keep content fresh and optimized Did you know that with [Article Generation](https://pollinations.ai/redirect-nexad/6QWh8zlE?user_id=983577), you can get 2,000-word SEO-optimized articles instantly? It could save you over $2,500 a month compared to hiring a writer! Think of it as having your own content team—minus all the management headaches.
Dưới đây là 3 thành phần của dịch vụ bảo trì và nó được xem như là bản chất của sự thành công:
• Bảo trì sửa lỗi: những dịch vụ hỗ trợ người dùng và sửa lỗi phần mềm
• Bảo trì thích ứng: làm cho các gói phần mềm thích ứng với những yêu cầu mới của khách hàng và điều kiện môi trường thay đổi
Bảo trì nâng cao chất lượng hệ thống bằng cách hoàn thiện các chức năng mới và tối ưu hóa hiệu suất phần mềm, đồng thời thực hiện bảo trì phòng ngừa để cải thiện độ tin cậy và củng cố cơ sở hạ tầng hệ thống Các hoạt động này giúp hệ thống hoạt động ổn định hơn, dễ dàng bảo trì trong tương lai và nâng cao trải nghiệm người dùng Việc kết hợp giữa bảo trì sửa chữa và bảo trì phòng ngừa góp phần giữ cho hệ thống luôn trong trạng thái tối ưu, đáp ứng tốt các yêu cầu vận hành và giảm thiểu rủi ro gian đoạn.
Các trung tâm hỗ trợ người dùng trong bảo trì và sửa lỗi đóng vai trò quan trọng trong việc cung cấp sự rõ ràng và hỗ trợ hiệu quả khi người dùng gặp sự cố Dịch vụ hỗ trợ này giải quyết tất cả các khó khăn phát sinh trong quá trình sử dụng hệ thống phần mềm, bao gồm cả các vấn đề về sửa lỗi phần mềm, thường được tích hợp trong dịch vụ hỗ trợ tổng thể Những trở ngại của người dùng có thể xuất phát từ các nguyên nhân như lỗi phần mềm, cấu hình sai hoặc thiếu hiểu biết về hệ thống, và việc cung cấp dịch vụ hỗ trợ rõ ràng giúp khắc phục nhanh chóng các vấn đề này, nâng cao trải nghiệm người dùng.
• Lỗi code (thường được dùng với thuật ngữ “thất bại phần mềm"-software failure”)
Lỗi viết tài liệu thủ công có thể gây ra sự không chính xác trong hướng dẫn, nhưng dịch vụ hỗ trợ vẫn cung cấp cho người dùng các chỉ dẫn đúng đắn để đảm bảo trải nghiệm thuận tiện Các màn hình hoặc tài liệu hướng dẫn được chuẩn bị sẵn giúp người dùng dễ dàng tiếp cận thông tin, mặc dù không đảm bảo tính chính xác tuyệt đối trong phần mềm Việc sử dụng tài liệu hướng dẫn thủ công giúp giảm thiểu lỗi và nâng cao hiệu quả hỗ trợ khách hàng trong quá trình vận hành.
• Không đầy đủ, mơ hồ hoặc tài liệu không chính xác
Người dùng thường gặp khó khăn do thiếu kiến thức về hệ thống phần mềm hoặc thất bại trong việc sử dụng tài liệu hướng dẫn được cung cấp, dẫn đến hiệu quả sử dụng phần mềm giảm sút Trong những trường hợp này, các vấn đề liên quan đến thất bại của hệ thống phần mềm thường không được xem xét, tập trung chủ yếu vào khả năng và hiểu biết của người dùng Việc đào tạo và cung cấp tài liệu rõ ràng là yếu tố quyết định để nâng cao trải nghiệm sử dụng phần mềm và giảm thiểu các lỗi không liên quan đến phần mềm.
Các nguyên nhân ban đầu thường liên quan đến những thất bại của hệ thống phần mềm, dẫn đến nhu cầu thực hiện các dịch vụ hỗ trợ người dùng và điều chỉnh phần mềm Việc tích hợp các dịch vụ hỗ trợ này thường được thực hiện một cách chặt chẽ, chia sẻ thông tin để nâng cao hiệu quả Trong khi đó, các hoạt động bảo trì nhằm cải thiện chất lượng và thích ứng phần mềm thường không bắt đầu từ các dịch vụ hỗ trợ người dùng, mà phụ thuộc vào yêu cầu của khách hàng để thực hiện các dự án nhỏ hoặc lớn Những công việc này thường được tích hợp vào quy trình phát triển phần mềm hiện tại, do đó, việc bao gồm dịch vụ hỗ trợ người dùng trong hoạt động bảo trì nhằm sửa đổi phần mềm là hoàn toàn hợp lý và cần thiết để nâng cao tính thích ứng và hiệu suất của hệ thống.
Việc bảo trì và sửa lỗi đảm bảo người dùng hiện tại có thể vận hành hệ thống một cách ổn định và hiệu quả Bảo trì thích ứng không chỉ duy trì hoạt động của hệ thống mà còn mở rộng khả năng cho nhiều nhóm người dùng khác nhau Ngoài ra, quá trình bảo trì cải thiện chất lượng dịch vụ, nâng cao trải nghiệm người dùng trong giai đoạn cung cấp dịch vụ của gói phần mềm.
Việc kết hợp ba thành phần bảo trì phần mềm chiếm hơn 60% tổng tài nguyên thiết kế và lập trình trong toàn bộ vòng đời của hệ thống (Pressman, 2000) Các ước lượng khác cho thấy tài nguyên bảo trì có thể chiếm hơn 50% đến 75% tổng nguồn lực phát triển dự án phần mềm (Lientz và Swanson, 1980), nhấn mạnh tầm quan trọng của hoạt động bảo trì trong quản lý vòng đời phần mềm.
Mục tiêu hoạt động QA bảo trì phần mềm:
(1) Đảm bảo, với mức độ tin cậy được chấp nhận, rằng những hoạt động bảo trì phù hợp với những yêu cầu kỹ thuật chức năng
(2) Đảm bảo, với mực độ tin cậy được chấp nhận, rằng những hoạt động bảo trì phù hợp với những yêu cầu quản lý lập lịch và ngân sách
Các hoạt động khởi đầu và quản lý nhằm nâng cao hiệu quả của bảo trì phần mềm và hoạt động SQA đóng vai trò quan trọng trong việc cải thiện tổng thể dự án Việc này giúp nâng cao nhìn nhận toàn diện về tiến trình, đảm bảo đáp ứng đầy đủ các yêu cầu chức năng và quản lý, đồng thời giảm thiểu chi phí Tối ưu hóa các bước này không chỉ nâng cao chất lượng phần mềm mà còn tăng tính cạnh tranh của sản phẩm trên thị trường.
3.4.2 Cơ sở cho chất lượng bảo trì cao
Chất lượng của gói phần mềm được bảo trì phụ thuộc chủ yếu vào chất lượng của dịch vụ bảo trì, được xem là yếu tố quan trọng nhất đảm bảo hiệu quả và độ tin cậy của phần mềm Tuy nhiên, một số nhà phê bình cho rằng chính sách bảo trì mới là yếu tố quyết định, ảnh hưởng lớn đến quá trình duy trì và phát triển phần mềm Dưới đây là các tranh luận xoay quanh vai trò của dịch vụ bảo trì và chính sách bảo trì trong việc nâng cao chất lượng phần mềm.
3.4.2.1 Cơ sở 1: Chất lượng gói phần mềm
Chất lượng của gói phần mềm được bảo trì phụ thuộc vào trình độ và nỗ lực của nhóm phát triển cùng các hoạt động SQA thực hiện xuyên suốt quá trình phát triển Nếu phần mềm có chất lượng kém, quá trình bảo trì cũng sẽ trở nên nghèo nàn hoặc không hiệu quả Việc hiểu rõ cơ sở này giúp chúng ta tập trung vào 7 trong 11 yếu tố đảm bảo chất lượng ban đầu có ảnh hưởng trực tiếp đến hoạt động bảo trì phần mềm Đặc biệt, chúng ta sẽ phân tích sâu về 2 yếu tố trong nhóm thao tác sản phẩm, 3 yếu tố trong nhóm xem xét lại sản phẩm, và 2 yếu tố trong nhóm chuyển giao sản phẩm.
Hai nhân tố thao tác sản phẩm:
• Sự chính xác (Correctness)– bao gồm:
Độ chính xác của đầu ra là yếu tố quan trọng, đảm bảo rằng các kết quả được hoàn thành chính xác và đầy đủ theo yêu cầu, không bỏ sót thông tin đã chỉ rõ Sự đúng đắn của đầu ra phản ánh việc hệ thống xử lý dữ liệu một cách chính xác, đảm bảo các kết quả phản ánh chính xác dữ liệu đầu vào Đầu ra hợp thời đòi hỏi thông tin luôn được cập nhật nhất quán và phản ánh trạng thái thực tế, giúp người dùng nắm bắt được dữ liệu mới nhất Ngoài ra, tính sẵn sàng của đầu ra đảm bảo các hệ thống không vượt quá các giới hạn tương tác tối đa, đặc biệt trong các ứng dụng trực tuyến và thời gian thực, nâng cao trải nghiệm người dùng và độ tin cậy của hệ thống.
Chất lượng của tài liệu hướng dẫn phụ thuộc vào độ chính xác, tính đầy đủ, đúng đắn, kiểu dáng và cấu trúc của nó Các hình thức tài liệu đa dạng, bao gồm bản sao trên giấy và các file điện tử, có thể là tài liệu in ấn hoặc file trợ giúp điện tử Phạm vi của tài liệu hướng dẫn bao gồm tài liệu cài đặt, hướng dẫn người dùng và tài liệu của nhà lập trình viên, góp phần nâng cao hiệu quả sử dụng và hỗ trợ kỹ thuật.
Viết mã đúng quy cách là yếu tố then chốt để đảm bảo tính ổn định và dễ bảo trì của phần mềm Điều này đặc biệt quan trọng khi tuân thủ các hướng dẫn mã nguồn, bao gồm các hạn chế và yêu cầu về độ phức tạp trong cấu trúc mã Việc xác định kiểu mã đúng chuẩn giúp tối ưu hóa hiệu suất và giảm thiểu lỗi, từ đó nâng cao chất lượng dự án phát triển phần mềm.
• Độ tin cậy Tần số của những thất bại của hệ thống cũng như những lần phục hồi
Ba nhân tố xem xét lại sản phẩm:
Sự bảo trì phần mềm bắt đầu bằng việc thực hiện theo cấu trúc phần mềm đã được thiết kế rõ ràng và các yêu cầu kỹ thuật trong tài liệu của lập trình viên Việc tuân thủ các yêu cầu này giúp đảm bảo quá trình bảo trì diễn ra thuận lợi, hiệu quả và đúng theo kế hoạch.