Quy trình phát triển PSP và ứng dụng - 8 pot

122
Số sai sót loại bỏ/giờ Đến ngày = 60*(Sai sót loại bỏ Đến ngày trong pha)/(số phút Đến
ngày bỏ ra trong pha)

Sinh viên Sinh viên X Ngày 28/11/96
Chương trình Chương trình # 14
Người hướng dẫn Thầy Z Ngôn ngữ Ada
Tóm tắt Kế hoạch Thực tế Đến ngày
Phút/LOC 5.73 4.65 5.48
LOC/Giờ 10.47 12.90 10.95
Sai sót/KLOC
96.90 77.9 92.53
Hiệu suất
33.3 80.0 40.0
A/FR

Kích thước chương trình
(LOC)

Tổng mới và thay đổi 67 77 335
Kích thước tối đa 85
Kích thước tối thiểu 49

Thời gian trong pha
(phút)
Kế hoạch Thực tế Đến ngày Đến ngày %
Lên kế hoạch 23 32 120 6.5
Thiết kế 39 44 195 10.6
Cài đặt 166 155 792 43.1
Xem lại mã 29 34 145 7.9
Biên dịch 24 8 100 5.5
Kiểm thử 62 39 279 15.2
Tổng kết 41 46 206 11.2
Tổng cộng 384 358 1837 100.0
Kích thước tối đa 487
Kích thước tối thiểu 281
Sai sót mắc phải Kế hoạch Thực tế Đến ngày Đến ngày % Sai
sót/giờ
Lên kế hoạch
Thiết kế 1 1 5 k 16.1 1.54
Cài đặt 5 4 25 k 80.7 1.89
Xem lại mã

Biên dịch 1 1 3.2
Kiểm thử
Tổng cộng 6 5 31 100.0


Sai sót loại bỏ Kế hoạch Thực tế Đến ngày Đến ngày % Sai
sót/giờ
Lên kế hoạch
Thiết kế
Cài đặt

Xem lại mã 2 4 12 38.7 4.97
Biên dịch 3 1 13 41.9 7.80
Kiểm thử 1 1 6 19.4 1.29
Tổng cộng 6 5 31 100.0
Bảng 3.6.2 Ví dụ bản tổng kết kế hoạch dự án









123
Khi loại bỏ sai sót trong một pha, bạn cũng sẽ muốn biết có bao nhiêu sai sót được
tìm thấy và bao nhiêu bị bỏ sót. Không có cách nào để biết được điều này vào lúc đang
phát triển, nhưng dữ liệu lịch sử có thể giúp bạn khá tốt về điều này bằng cách tính toán và
theo dõi chỉ số hiệu suất. Với PSP, hiệu suất quy trình được định nghĩa là phần trăm sai sót
tìm thấy trước khi biên dịch và kiểm thử l
ần đầu. Bảng trên là ví dụ minh họa về cách tính
các số liệu trên.
3.6.4 Tăng tỉ lệ loại bỏ sai sót
Bạn có thể cải tiến nhanh chóng tỉ lệ loại bỏ sai sót bằng cách thực hiện xem lại
code. Tuy nhiên, một khi bạn đạt được các lợi ích cải tiến ban đầu này, việc cải tiến xa hơn
nữa sẽ khó khăn hơn. Bởi vì thử thách đối đầu với các kỹ sư phần mềm tăng dần theo mỗi
năm, bạn không được phép ngừng cải tiến. Một số lờ
i khuyên cho việc tiếp tục cải tiến tỉ lệ
loại bỏ sai sót của bạn là:
- Tập trung vào hiệu suất trước tiên. Hãy nhớ rằng, mục tiêu là loại bỏ tất cả các

sai sót. Mục tiêu đầu tiên của bạn vì vậy là phải đạt được hiệu suất 70% hay
nhiều hơn.
- Thực hiện xem lại code trước khi biên dịch lần đầu. Để đạt được hiệu suấ
t cao
nhất có thể, sử dụng trình biên dịch để kiểm tra chất lượng của việc xem lại
code của bạn.
- Một khi bạn đã đạt được hiệu suất đáng kể, sử dụng các phương pháp ở các
phần trước để cải tiến tốc độ xem lại. Theo dõi xem checklist tìm thấy và bỏ sót
sai sót ở đâu và thực hiện điều chỉnh định kỳ. Nế
u có một số bước không tìm
thấy hay không bỏ sót nhiều sai sót, hãy nghĩ đến việc loại chúng ra. Tuy nhiên,
khi bạn vẫn tiếp tục bỏ sót sai sót, hãy xem xét việc thêm vào một bước trong
checklist để một cách đặc biệt nhằm vào loại này.
- Nếu bạn cứ làm hoài một việc thì đừng mong có một kết quả khác đi. Nếu bạn
không thay đổi checklist, bạn sẽ vẫn tiếp tục bỏ sót cũng các sai sót đó.
Hãy tiếp t
ục thu thập dữ liệu sai sót, tính toán hiệu suất, tỉ lệ mắc phải sai sót và
loại bỏ sai sót. Sau đó, theo dõi các dữ liệu này và thí nghiệm với nhiều phương pháp khác
nhau để tìm được đúng phương pháp giúp bạn cải tiến.









124
3.6.5 Giảm tỉ lệ mắc phải sai sót

Để giảm tỉ lệ mắc phải sai sót thì khó hơn vì bạn mắc phải sai sót trong mọi phần
của quy trình. Vì vậy một số cách để giảm tỉ lệ sai sót như sau:
Ghi nhận lại tất cả sai sót của bạn. Có ý thức về các sai sót của mình, bạn sẽ làm
việc cẩn thận hơn và sẽ giảm được số lượng sai sót mắc phải.
Tạo ra các thiết kế tốt hơn
. Tạo ra các thiết kế hoàn chỉnh hơn và được sưu liệu tốt,
bạn có thể cải tiến chất lượng chương trình theo 2 phương diện. Đầu tiên, điều này sẽ thật
sự ngăn chặn các sai sót mà một bản thiết kế không hoàn chỉnh hay khó hiểu gây ra. Thứ
hai, một thiết kế hoàn chỉnh hơn sẽ tiết kiệm thời gian cài đặt. Bởi vì tỉ lệ mắc phải sai sót
trong thi
ết kế thì thấp hơn trong cài đặt nên điều này cũng sẽ giảm được sai sót.
Sử dụng các phương pháp tốt hơn. Vì sai sót có thể bị mắc phải trong bất cứ pha
nào, cải tiến cách bạn phát triển yêu cầu, đặc tả, thiết kế, trường hợp kiểm thử và mã nguồn
đều giúp để giảm sai sót. Bằng cách sử dụng PSP và đánh giá công việc của bạn bằng các
phương pháp này, bạ
n có thể thấy chúng làm tốt như thế nào.
Sử dụng các công cụ tốt hơn. Nếu một công cụ tiết kiệm thời gian thì nó sẽ giảm số
sai sót mà bạn mắc phải. Các công cụ phần mềm mới được phát triển hàng năm và dữ liệu
PSP sẽ cho phép bạn đo lường và đánh giá chúng. Khi đó bạn có thể biết được công cụ nào
giúp bạn và đến mức nào.
3.7 Các sai sót thiết kế
3.7.1 Tính tự nhiên của sai sót thiết kế
Nhiều sai sót tìm thấy trong kiểm thử hầu như chắc chắn là bị mắc trong pha cài
đặt. Điều này hàm ý vấn đề sai sót chủ yếu là các lỗi cài đặt đơn giản. Thật ra, với các lỗi
tìm thấy trong kiểm thử, 14 sinh viên trong một lớp của tác giả Humphrey đã mắc lại một
nửa số lỗi trong cài đặt như họ đã từng mắc trong thiết kế. Vì trình biên dịch đã loại b
ỏ hầu
hết các sai sót về lỗi cú pháp nên điều này khá ngạc nhiên. Tuy nhiên, như bạn có thể thấy
ở bảng 2.16.1, tỉ lệ này thay đổi khi sinh viên học PSP. Trong số sai sót tìm thấy trong
kiểm thử, các sinh viên khi mới bắt đầu học PSP mắc sai sót trong cài đặt nhiều gấp rưỡi

lần so với trong thiết kế. Đến cuối khoá học, con số này nhiều hơn chỉ là khoảng 14%. Ta
thấy họ giảm số lượng sai sót mắ
c phải cả trong 2 pha, nhưng việc cải tiến có phần hơi ít
với các sai sót kiểm thử mắc phải trong thiết kế (xem %Giảm trong bảng dưới).