Phần này đưa ra vấn đề về các sai sót phần mềm. Sai sót có thể gây ra các vấn đề nghiêm trọng cho người dùng sản phẩm phần mềm và việc tìm và sửa chúng thì lại đắt đỏ. Vì sai sót gây ra bởi lỗi của nhà phát triển, các kỹ sư cần phải hiểu sai sót họ mắc phải và học cách để quản lý chúng. Bước đầu tiên trong quản lý sai sót là tập hợp dữ liệu về sai sót mà bạn mắc phải trong chương trình. Với các dữ liệu này, bạn có thể nghĩ ra cách tốt hơn để tìm và sửa chúng.
Cho đến bây giờ, chúng ta chỉ nói về các phương pháp để quản lý chi phí và lịch biểu. Tuy nhiên đây mới chỉ là một nửa đoạn đường. Bắt đầu phần này sẽ chỉ ra nhu cầu cần phải sản xuất ra các sản phẩm phần mềm có chất lượng. Đầu tiên, chúng ta cần phải định nghĩa chất lượng là gì.
3.2.1 Chất lượng phần mềm là gì?
Chất lượng phần mềm ảnh hưởng rất lớn đến chi phí phát triển, kế hoạch chuyển giao sản phẩm và sự thoả mãn của khách hàng về sản phẩm. Vì chất lượng phần mềm quan trọng như vậy, đầu tiên chúng ta cần thảo luận chúng ta nói gì với từ Chất lượng. Chất lượng của sản phẩm phần mềm phải được định nghĩa bằng những thuật ngữ có ý nghĩa đối với người dùng sản phẩm. Một sản phẩm cung cấp được các khả năng quan trọng nhất đối với người dùng thì là một sản phẩm có chất lượng. Nhu cầu của người dùng thường được chỉ ra trong các tài liệu về yêu cầu. Cần phải nhớ rằng bạn không thể phát triển một chương trình có chất lượng cho đến khi bạn có các yêu cầu rõ ràng. Bạn có thể không bắt đầu với các yêu cầu rõ ràng nhưng bạn phải hiểu được yêu cầu trước khi bạn có thể hoàn tất.
3.2.2 Sai sót và chất lượng
Công việc của kỹ sư phần mềm là sản xuất ra các sản phẩm có chất lượng với chi phí mong đợi và đúng kế hoạch. Sản phẩm phần mềm phải đáp ứng được nhu cầu về chức năng của người dùng và thực hiện công việc của người dùng một cách đáng tin cậy và nhất quán. Thực hiện công việc là điểm mấu chốt. Các chức năng phần mềm thì quan trọng nhất đối với người dùng và các chức năng này sẽ không dùng được trừ khi phần mềm chạy. Để phần mềm chạy thì bạn phải loại bỏ các sai sót của nó. Vì vậy, có rất nhiều khía cạnh của chất lượng phần mềm nhưng mối quan tâm chất lượng đầu tiên của bạn phải là sai sót của nó. Điều này không có nghĩa sai sót là mối quan tâm duy nhất của bạn hay chúng là quan trọng nhất, mà chỉ khi bạn giải quyết được hầu hết các sai sót thì bạn mới có thể thỏa mãn được bất cứ mục tiêu nào khác của chương trình. Ngay cả khi bạn làm cho chương trình hoạt động được mà chúng vẫn còn một số lỗi thì chúng cũng sẽ không hoạt động trong các hệ thống lớn và sẽ không ai sử dụng chúng, bất chấp các chất lượng khác của chúng.
Lý do mà sai sót lại quan trọng đến thế là do con người vẫn hay phạm rất nhiều lỗi. Trong thực tế, ngay cả những lập trình viên kinh nghiệm vẫn thường mắc 1 sai sót cho mỗi 7 đến 10 dòng lệnh mà họ viết. Có thể họ sẽ tìm ra và chỉnh sửa hầu hết các lỗi trong lúc biên dịch và kiểm tra chương trình, nhưng thường vẫn có nhiều sai sót còn tồn tại ở sản phẩm cuối. Rõ ràng lúc này, nhiệm vụ ưu tiên hàng đầu của bạn là hiểu được các sai sót bạn mắc phải và tránh được càng nhiều càng tốt. Để làm được việc này, bạn cần thành thạo ngôn ngữ bạn sử dụng, cần hiểu sâu sắc về hệ thống hỗ trợ phát triển và phải nắm vững các
ứng dụng bạn sẽ phát triển. Những bước này và nhiều hơn nữa được yêu cầu để làm giảm bớt sai sót mà bạn mắc phải.
3.2.3 Sai sót là gì?
Thuật ngữ sai sót liên quan đến một cái gì đó sai trong chương trình, như lỗi cú pháp, viết sai chính tả, lỗi dấu câu hay một phát biểu chương trình không đúng. Sai sót có thể xuất hiện trong chương trình, thiết kế hay thậm chí trong yêu cầu, đặc tả hay trong các tài liệu khác. Sai sót có thề là một câu lệnh thừa, một câu lệnh không chính xác hay những phần chương trình bị lược bỏ. Nói tóm lại, sai sót là bất cứ thứ gì làm giảm đi khả năng của chương trình để đáp ứng hoàn toàn và có hiệu quả nhu cầu của người sử dụng. Đó là một thứ mà bạn có thể xác định, mô tả và đếm.
Những lỗi cài đặt đơn giản có thể sản sinh ra những sai sót nguy hiểm và khó tìm thấy. Ngược lại, có nhiều sai sót thiết kế phức tạp nhưng lại dễ dàng nhận thấy. Vì vậy độ phức tạp của sai sót thiết kế và ảnh hưởng của sai sót phần lớn là độc lập nhau. Ngay cả những lỗi thực thi tầm thường cũng có thể gây ra những vấn đề nghiêm trọng cho hệ thống. Quan trọng là cần tách biệt vấn đề tìm hay nhận diện sai sót khỏi việc xác định nguyên nhân của chúng. Việc đếm hay ghi nhận các sai sót một cách đơn giản trong sản phẩm phần mềm thì không xác định được nguyên nhân hay đưa ra trách nhiệm. Tuy nhiên, sai sót lại có nguyên nhân. Có thể bạn đã viết sai chính tả một tham số, bỏ sót một dấu chấm câu hay gọi một hàm không đúng. Tất cả những lỗi này đều gây ra sai sót. Tóm lại, tất cả sai sót bắt nguồn từ lỗi của con người và nhiều lỗi mà kỹ sư phần mềm gây ra thì gọi là sai sót chương trình.
Lỗi là những gì không đúng mà con người gây ra và bất chấp việc khi nào hay ai tạo ra chúng, sai sót là yếu tố khuyết điểm của chương trình. Vì vậy, con người tạo ra lỗi còn chương trình thì có sai sót. Điều này có nghĩa là để giảm sai sót bạn mắc phải trong sản phẩm, bạn phải thay đổi những gì bạn làm. Tuy nhiên, để loại bỏ sai sót khỏi sản phẩm của bạn, thường thì bạn chỉ cần tìm chúng. Loại bỏ sai sót vì vậy là một quy trình dễ hơn là ngăn ngừa sai sót. Ngăn ngừa sai sót là một đề tài chính yếu và quan trọng đòi hỏi việc nghiên cứu toàn diện về toàn bộ quy trình phát triển phần mềm.
Vấn đềđặt ra là cần nhiều thời gian và tiền bạc để tìm và sửa sai sót phần mềm. Để ít mắc lỗi hơn, bạn phải cố gắng học hỏi từ những sai sót đã mắc phải trước đó, nhận diện được các lỗi tạo ra chúng, và học cách tránh lặp lại sai sót tương tự trong tương lai. Vì các sản phẩm khuyết điểm có thể rất đắt đỏđể kiểm thử, khó sửa chữa và có thể nguy hiểm khi
sử dụng, điều quan trọng là bạn phải học cách giảm thiểu sai sót bạn để lại trong sản phẩm. Tài liệu này sẽ giúp bạn làm điều đó.
Một số phần trăm của sai sót trong một chương trình có thể có các hậu quả không lường trước được. Nếu chúng ta có thể biết được chúng là những sai sót nào thì khi đó chúng ta chỉ cần sửa chúng và không còn lo lắng gì nữa. Không may là không có cách nào để làm điều này và bất cứ sai sót bị bỏ sót nào đều có thể gây nên hậu quả nghiêm trọng. Bây giờ có thể sai sót không là vấn đề nghiêm trọng với bạn, nhưng không sớm thì muộn. Vì vậy quan trọng là bạn phải học cách quản lý sai sót ngay từ bây giờ để bạn có thể sẵn sàng khi thật sự cần phải sản xuất ra các chương trình chất lượng cao.
Kỹ sư phần mềm - những người viết chương trình - là những người có thể tìm và vá lỗi tốt nhất. Vì vậy quan trọng là kỹ sư phần mềm cần phải có trách nhiệm cá nhân cho chất lượng của chương trình mà họ viết. Tuy nhiên, việc học cách để viết các chương trình không-lỗi là một thách thức lớn. Đó không phải là điều mà bất cứ ai cũng có thể thực hiện nhanh chóng và dễ dàng. Cần phải có dữ liệu, các kỹ thuật hiệu quả và kỹ năng. Sử dụng các phương pháp được mô tả ởđây bạn có thể phát triển và mài dũa khả năng sản xuất ra các chương trình chất lượng cao. Sau cùng, nếu bạn không cố gắng để thực hiện một công việc không có lỗi thì sẽ chẳng bao giờ bạn có thể làm được cả.
3.2.4 Các loại sai sót
Để phân tích các sai sót thì cách hữu ích là nên phân loại chúng. Tài liệu này phân sai sót ra thành 10 loại chung. Bằng việc phân loại này, bạn sẽ nhanh chóng tìm ra loại nào gây ra vấn đề nhất để tập trung vào việc ngăn chặn và loại bỏ nó. Tất nhiên, đây là điều then chốt của quản lý sai sót. Tập trung giải quyết một số ít sai sót gây rắc rối nhất. Một khi đã kiểm soát được chúng, hãy tiếp tục với các sai sót tiếp theo, và cứ như vậy.
Trong bảng sau là danh sách 10 loại sai sót, xuất phát từ thành quả công việc của Chillarege cùng các đồng sự khi nghiên cứu ở IBM. Ông đã nghiên cứu về các sai sót trên một diện rộng các sản phẩm IBM và nhận ra các loại chính của chúng. Các loại này cũng được nhận thấy là có ích cho PSP.
Loại số Tên loại Mô tả
10 Sưu liệu (documentation) Lời bình, thông điệp
20 Cú pháp Lỗi chính tả, lỗi chấm câu, lỗi do gõ phím, các định dạng chỉ thị, lệnh
30 Xây dựng, đóng gói Quản lý thay đổi, thư viện, điều khiển các phiên bản 40 Chỉđịnh Khai báo, trùng tên, phạm vi, giới hạn
50 Giao diện (Interface) Lời gọi hàm, các tham chiếu, nhập/xuất (I/O), định dạng người dùng
60 Kiểm tra (Checking) Thông điệp báo lỗi, kiểm tra không thích hợp 70 Dữ liệu cấu trúc, nội dung
80 Chức năng Logic, con trỏ, vòng lặp, đệ qui, tính toán, sai sót chức năng
90 Hệ thống Cấu hình, sựđịnh giờ, bộ nhớ
100 Môi trường Thiết kế, biên dịch, kiểm tra, những vấn đề hệ thống hỗ trợ khác
Bảng 3.2.1 Chuẩn các loại sai sót
Trong bảng trên, các loại sai sót dựa vào các loại vấn đề có đặc điểm chung. Ví dụ, loại 20 – sai sót cú pháp đề cập đến tất cả những gì được tạo ra nhưng không đúng đặc tả của ngôn ngữ lập trình. Có thểđó là thiếu “;”, câu lệnh if không đúng, lỗi chính tả hay khai báo sai. Sai sót loại 20 là bất cứ sai sót nào dẫn đến cú pháp chương trình không đúng, bất chấp việc sai sót đó bị gây ra hay được tìm thấy như thế nào. Một loại sai sót khác như là 80 – chức năng và ví dụ cho loại này như là một vòng lặp do-while với logic sai trong điều kiện while.
Các loại sai sót trong bảng được sắp xếp theo độ phức tạp của nguyên nhân gây ra có thể có. Ví dụ, loại 10, 20, 30 thường bắt nguồn từ các lỗi hay sơ suất đơn giản. Tuy nhiên, loại 80, 90, 100 lại thường liên quan đến vấn đề thiết kế phức tạp hơn hay là các vấn đề về hệ thống. (adsbygoogle = window.adsbygoogle || []).push({});
Thay vì cải tiến từng 10 loại sai sót PSP này thành các loại con, hãy chờ cho đến khi bạn đã tập hợp được dữ liệu ít nhất 100 sai sót của một số chương trình. Khi đó, bạn có thể thấy được chỗ nào cần chi tiết thì tốt hơn và cần thêm thông tin cụ thể nào. Ví dụ, bạn có thể chia loại 20 – sai sót cú pháp thành các loại con như loại 21 cho sai sót về “;”, 22 cho các sai sót dấu câu khác, 23 cho vấn đề về biểu thức Boolean, 24 cho các dạng chỉ thị lệnh sai, v.v…
3.2.5 Hiểu được các sai sót
Bước đầu tiên để quản lý được các sai sót là phải hiểu được chúng. Để làm được điều này, bạn cần tập hợp các dữ liệu sai sót. Khi đó bạn có thể hiểu được các lỗi này và
luận ra được cách tránh chúng. Ngoài ra bạn có thể luận ra được cách tốt nhất để tìm, sửa hoặc thậm chí là ngăn chặn các sai sót mà bạn vẫn còn mắc phải.
Để tập hợp được dữ liệu sai sót trong chương trình, cần làm theo những bước sau: - Giữ lại ghi nhận về mỗi sai sót bạn tìm thấy trong chương trình.
- Ghi nhận lại thông tin đầy đủ cho mỗi sai sót để sau này bạn có thể hiểu nó. - Phân tích những dữ liệu này để thấy được loại sai sót nào gây ra hầu hết các vấn đề.
- Nghĩ ra cách để tìm ra sai sót và chỉnh sửa những sai sót này.
Những sai sót bạn mắc phải và tìm thấy trong chính chương trình của mình chỉ là một phần của vấn đề. Một lúc nào đó bạn sẽ cần phải tìm hiểu về các sai sót mà người khác tìm thấy trong chương trình của bạn. Vì các sai sót này đã thoát khỏi sự ngăn ngừa sai sót và nỗ lực tìm kiểm của bạn nên chúng rất quan trọng trong việc hiểu và chỉ ra các điểm yếu trong quy trình cá nhân của bạn. Khi quy trình cá nhân của bạn được cải thiện các sai sót bị bỏ sót này cuối cùng sẽ là nguồn dữ liệu chính cho việc cải tiến cá nhân của bạn.