Bản ghi ghi chép sai sót (Defect Recording Log)

Một phần của tài liệu quy trình PSP (Trang 96 - 100)

Sinh viên Ngày

Người hướng dẫn Chương trình #

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa Mô tả Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa Mô tả Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa Mô tả

Bảng 3.2.2 Bản ghi ghi chép sai sót

Bản ghi ghi chép sai sót được thiết kếđể giúp cho việc thu thập dữ liệu sai sót. Sử dụng bản ghi này để tập hợp dữ liệu sai sót cho mỗi chương trình mà bạn viết. Mô tả mỗi

Loại sai sót

10 Sưu liệu 60 Kiểm tra 20 Cú pháp 70 Dữ liệu 30 Xây dựng, đóng gói 80 Chức năng 40 Chỉđịnh 90 Hệ thống 50 Giao diện 100 Môi trường

sai sót đủ chi tiết để sau này bạn có thể hiểu nó. Sau khi hoàn tất mỗi chương trình, phân tích dữ liệu để thấy được ở chỗ nào bạn mắc phải và loại bỏ sai sót và loại sai sót nào gây rắc rối nhất.

Mục đích Biểu mẫu này lưu giữ những dữ liệu về các sai sót mà bạn tìm thấy và chỉnh sửa. Sử dụng các dữ liệu này để hoàn tất bản tổng kết kế hoạch dự án

Tổng quát Ghi nhận tầt cả các sai sót xem lại, biên dịch, kiểm thử trong bản ghi này. Ghi nhận mỗi sai sót một cách riêng biệt và hoàn chỉnh.

Đầu đề Ghi những thông tin sau:

- Tên

- Ngày lập

- Tên người hướng dẫn - Số của chương trình

Ngày Ghi nhận lại ngày mà sai sót được phát hiện Số Đánh số mỗi sai sót

Với mỗi chương trình, sử dụng chuỗi số liên tiếp bắt đầu bằng 1 (hay 001, v.v…)

Loại Ghi nhận loại sai sót từ danh sách các sai sót trong bảng trên.

Sử dụng sự phán đoán của bạn trong việc chọn loại sai sót nào thích hợp Mắc phải Ghi nhận lại pha mà trong đó sai sót bị mắc phải

Loại bỏ Ghi nhận lại pha mà trong đó sai sót được loại bỏ Thời gian

sửa chữa

Ước tính hay đo thời gian cần thiết để tìm và chỉnh sửa lỗi. Sai sót sửa

chữa

Bạn có thể bỏ qua mục này trong lúc này.

Nếu bạn mắc phải sai sót này trong khi đang chỉnh sửa sai sót khác, ghi nhận lại số sai sót đã chỉnh sửa sai này

Mô tả Viết mô tả ngắn gọn về sai sót.

Mô tảđủ rõ ràng để sau này nó nhắc lại cho bạn nhớ về lỗi gây ra sai sót và tại sao bạn mắc phải.

Bảng 3.2.3 Các chỉ dẫn bản ghi ghi chép sai sót

Phần sau sử dụng bản ghi ghi chép sai sót ví dụ trong bảng 3.2.4 để hướng dẫn cách hoàn tất bản ghi:

1. Khi bắt đầu phát triển một chương trình, lấy vài trang bản ghi ghi chép sai sót và điền thông tin đầu đề của trang đầu tiên.

2. Khi bạn tìm thấy sai sót đầu tiên, ghi nhận lại số thứ tự của sai sót trong bản ghi, nhưng không ghi nhận các thông tin khác cho đến khi bạn chỉnh sửa được sai sót. Khi sinh viên X thử biên dịch chương trình 10 lần đầu tiên, trình biên dịch hiển thị hơn một tá thông điệp lỗi. Mặc dù cậu không biết ngay vấn đề là gì, nhưng cậu biết có ít nhất một lỗi sai. Vì vậy cậu ghi lại thời gian và điền 1 dưới mục Sốở dòng đầu tiên của bản ghi sai sót vì đây là lỗi đầu tiên của chương trình 10. Các con số này về sau sẽ giúp bạn trong việc phân tích dữ

liệu sai sót. Trong các chương trình lớn hơn, số thứ tự sai sót được dùng để theo dõi vấn đề sửa lỗi không đúng và giúp ngăn chặn sai sót.

Loại sai sót

10 Sưu liệu 60 Kiểm tra 20 Cú pháp 70 Dữ liệu 30 Xây dựng, đóng gói 80 Chức năng 40 Chỉđịnh 90 Hệ thống 50 Giao diện 100 Môi trường

Sinh viên Sinh viên X Ngày 28/10/96 Người hướng dẫn Thầy Z Chương trình # 10

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 28/10 1 20 Cài đặt Biên dịch 1 phút Mô tả Thiếu “;” Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 2 20 Cài đặt Biên dịch 1 phút Mô tả Thiếu “;” Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 3 40 Thiết kế Biên dịch 1 phút

Mô tả Kiểu sai do RSH của toán tử nhị phân, phải chuyển kiểu integer sang float

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 4 40 Cài đặt Biên dịch 1 phút

Mô tả Kiểu sai do RSH, hằng phải là 0.0 chứ không phải 0

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 5 40 Cài đặt Biên dịch 1 phút

Mô tả Kiểu sai do RSH, phải chuyển kiểu integer sang float

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 6 40 Thiết kế Biên dịch 7 phút

Mô tả Số mũ phải là integer, tìm hiểu lại và sử dụng thư viện math cho hàm sqrt. Số nguyên thì không được tính toán đúng đắn.

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 7 80 Cài đặt Kiểm thử 14 phút

Mô tả Đáp án (std. dev.) không đúng – viết code không đúng, viết trừ thay vì chia

Ngày Số Loại Mắc phải Loại bỏ T/g sửa chữa Sai sót sửa chữa 8 80 Cài đặt Kiểm thử 28 phút

Mô tả Vòng lặp không kết thúc do số mũ âm, quên đổi dấu khi trừ.

3. Sử dụng một dòng riêng biệt cho từng sai sót. Không nên nhóm các sai sót lại trên cùng một dòng.

4. Ghi nhận ngày sai sót được phát hiện. Nếu bạn phát hiện nhiều lỗi trong cùng 1 ngày, bạn có thểđể trống các mục ngày tiếp theo cho đến mục đầu tiên của ngày kế tiếp. Trong bảng 3.2.4, sinh viên X tìm thấy tất cả các sai sót vào ngày 28/10, vì vậy cậu không cần nhập lại ngày vì nó được ngầm hiểu là “như trên” cho đến khi có sự thay đổi.

5. Sau khi sửa lỗi xong, ghi nhận loại sai sót. Có thể bạn cảm thấy lúng túng về việc loại sai sót nào thì phù hợp, hãy sử dụng óc phán đoán của bạn. Đừng phí thời gian lo lắng về việc loại sai sót nào mới chính xác nhưng bạn cũng cần nhất quán một cách hợp lý. Về sai sót 1 trong bảng 3.2.4, sinh viên X phát hiện ra rằng vấn đề là thiếu dấu “;”. Khi đã giải quyết xong vấn đề, cậu ghi nhận lại con số 20 dưới mục Loại cho sai sót 1.

6. Ghi nhận pha của quy trình khi bạn mắc phải sai sót. Không phải điều này lúc nào cũng rõ ràng nhưng nó không nên là vấn đề cho các chương trình nhỏ. Sử dụng phán đoán tốt nhất của bạn và đừng phí thời gian lo lắng về nó. Trong ví dụ này, sinh viên X tự tin rằng cậu đã phạm sai sót khi thiếu “;” khi đang viết chương trình, vì vậy cậu ghi nhận từ “cài

đặt” dưới mục Mắc phải.

7. Ghi nhận lại pha trong qui trình mà bạn loại bỏđược sai sótĐây thường là pha khi bạn tìm thấy sai sót. Ví dụ, ởđây, với sai sót 1, sinh viên X đang ở pha biên dịch khi cậu tìm thấy và chỉnh sửa sai sót, vì vậy cậu ghi nhận từ “biên dịch” ở mục Loại bỏ.

8. Với thời gian chỉnh sửa sai sót, ước lượng thời gian từ khi bạn bắt đầu biết được và bắt đầu làm việc với sai sót cho đến khi bạn hoàn tất việc chỉnh sửa và kiểm tra nó. Khi bắt đầu chỉnh sửa sai sót 1, sinh viên X ghi lại thời gian trên đồng hồ của mình. Khi cậu đã sửa xong sai sót và kiểm tra để biết chắc chắn nó được sửa đúng, một lần nữa cậu lại xem đồng hồ và thấy cấu chỉ bỏ ra khoảng 1 phút. Thông thường, với các sai sót biên dịch, thời gian sửa chữa sẽ chỉ là 1 phút hoặc hơn chút xíu. Tuy nhiên, với các sai sót tìm thấy trong pha kiểm thử, việc sửa sai có thể chiểm nhiều thời gian hơn. Bạn có thể sử dụng đồng hồ hay đồng hồ bấm giờđểđo thời gian sửa chữa, nhưng với các sửa chữa ngắn thì việc bạn phán đoán thường sẽ thích hợp hơn.

9. Mục sai sót sửa chữa là các sai sót mắc phải khi đang chỉnh sửa các sai sót khác.

10. Viết một mô tả ngắn gọn về các sai sót trong phần mô tả. Mô tả càng ngắn và càng đơn giản càng tốt nhưng phải rõ ràng. Ví dụ, chỉ cần ghi nhận một dấu “;” để chỉ việc thiếu “;”. Với một sai sót phức tạp hơn, hãy viết một vài dòng nếu cần. Với sai sót 1, sinh viên X

chỉđơn giản ghi “thiếu ;”. Với hầu hết các sai sót trong bảng 3.2.4, cậu phải đưa ra một mô tả chi tiết hơn. Tuy nhiên, bởi vì mô tả này chỉđể cho bạn sử dụng nên không cần phải viết gì nhiều hơn cần thiết để nhắc cho bạn nhớ về vấn đề.

Người ta thường lúng túng về loại sai sót và nghĩ rằng nên có một loại riêng dành cho việc hiểu sai và nhầm lẫn. Ví dụ, nếu bạn không hiểu yêu cầu hoặc không quen với môi trường phát triển, bạn sẽ phạm nhiều sai sót. Vấn đề này thì quan trọng, nhưng nó lại liên quan đến nguyên nhân sai sót. Vì chỉ có loại của sai sót là liên quan nên chỉ có 2 câu hỏi: Có phải có gì sai trong sản phẩm và nếu như vậy thì loại của sai sót là gì? Vì vậy, mặc dù hiểu nguyên nhân thì rẩt cần thiết để ngăn chặn sai sót nhưng loại của sai sót chỉ mô tả điều gì sai trong sản phẩm mà thôi.

Một phần của tài liệu quy trình PSP (Trang 96 - 100)

Tải bản đầy đủ (PDF)

(191 trang)